[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#16526: 24.3.50; scroll-conservatively & c-mode regression
From: |
Alan Mackenzie |
Subject: |
bug#16526: 24.3.50; scroll-conservatively & c-mode regression |
Date: |
Sun, 2 Feb 2014 17:40:50 +0000 |
User-agent: |
Mutt/1.5.21 (2010-09-15) |
Hello, Eli.
On Sat, Feb 01, 2014 at 12:41:51PM +0200, Eli Zaretskii wrote:
> > Date: Thu, 30 Jan 2014 19:58:17 +0100
> > From: martin rudalics <rudalics@gmx.at>
> > CC: acm@muc.de, 16526@debbugs.gnu.org
> > > It takes about 11 sec here. But reverting the patch doesn't change
> > > this timing, I still get 11 sec.
> > But it does take longer with a maximized window?
> Yes, it does.
> > If so, do you have an explanation?
> Those 11 seconds are spent inside 'recenter', which is called by
> end-of-buffer:
> ;; If we went to a place in the middle of the buffer,
> ;; adjust it to the beginning of a line.
> (cond ((and arg (not (consp arg))) (forward-line 1))
> ((and (eq (current-buffer) (window-buffer))
> (> (point) (window-end nil t)))
> ;; If the end of the buffer is not already on the screen,
> ;; then scroll specially to put it near, but not at, the bottom.
> (overlay-recenter (point))
> (recenter -3)))) <<<<<<<<<<<<<<<<<<<<<<<<<<
> Stepping through 'recenter', I see the following:
> . It treats GUI frames specially (and indeed, in "emacs -nw", I
> don't see this slowdown). The special handling is that it
> attempts to find the window-start point that corresponds to the -3
> argument, by interpreting that argument as the number of pixels
> equivalent to 3 canonical-height lines.
> . To this end, 'recenter' calls move_it_vertically_backward with the
> -3 argument converted to pixels. move_it_vertically_backward then
> tries to find that place, by simulating display.
> . As part of the display simulation, jit-lock-function is called
> (because we hit a buffer position which has a non-nil 'fontified'
> property) with a single argument: buffer position 948757. This
> single call takes almost all of the 11 seconds.
> When the frame is not maximized, the window height is smaller, so
> 'recenter' moves back a smaller amount of pixels, and calls
> jit-lock-function at a different buffer position. That call takes
> only about 2 sec (still quite a lot, IMO).
> Perhaps Alan could explain why the CC Mode fontification takes such a
> long time for buffer position 948757.
No, sorry I can't explain it. Except that CC Mode will be scanning
forward through the entire buffer once (hopefully only once) to get the
"parse state" near EOB.
On a normally optimised 24.3 build, M-x goto-char 948757 is taking me a
little over a second. This is in a GUI frame in X Windows, maximised by
clicking on the maximise button at the top right of the frame.
On my non-optimised 24.3.50 build with tracing built in, the same action,
M-x goto-char 948757 takes 9 seconds. In a non-maximised frame it takes
8 seconds. In this build, M-> takes ~2 seconds regardless of whether the
frame is maximised or not. I can't explain this difference.
I've committed my patch. I hope it clears up the bug (which I haven't
yet closed) more or less satisfactorally.
--
Alan Mackenzie (Nuremberg, Germany).