GNU bug report logs - #17124
24.3.50; Occasional Extremely Slow Redraws in OSX Emacs

Previous Next

Full log

Message #25 received at 17124 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Eric Froemling <ericfroemling <at> gmail.com>
Cc: 17124 <at> debbugs.gnu.org
Subject: Re: bug#17124: 24.3.50; Occasional Extremely Slow Redraws in OSX Emacs
Date: Tue, 01 Apr 2014 18:03:18 +0300

> From: Eric Froemling <ericfroemling <at> gmail.com>
> Date: Mon, 31 Mar 2014 22:23:33 -0700
> Cc: 17124 <at> debbugs.gnu.org
> 
> Ok here’s some further info/possible repro case if it is of use:
> I built my own emacs by doing a bzr branch bzr://bzr.sv.gnu.org/emacs/trunk,
> then autogen.sh and ./configure —with-ns
> I removed my .emacs file so as to get default settings, then launched emacs,
> opened a large text file, and subdivided the frame into several windows.
> With this setup it is quite easy for me to get the slowdown to happen by just
> dragging a divider around for a bit.
> Here’s a clip of a slowdown with the activity monitor visible:
> https://www.youtube.com/watch?v=olkyqVOWSLs
> You can see that emacs is only using a few percent cpu throughout the slow redraw,
> whatever that may imply.

If Emacs does not use too much CPU cycles, it's probably not an Emacs
problem.

> I’ve also attached a sample I took of emacs during such a slowdown.
> It looks like a lot of calls are blocking in _CGSSynchronizeWindowBackingStore
> under the hood.

I don't know how to read that.  Are the numbers there CPU times, or
are they numbers of calls to each function?  If the latter, then they
are not very useful in this case.

Thanks.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.