GNU bug report logs - #16526
24.3.50; scroll-conservatively & c-mode regression

Previous Next

Full log

View this message in rfc822 format

From: Alan Mackenzie <acm <at> muc.de>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: martin rudalics <rudalics <at> gmx.at>, 16526 <at> debbugs.gnu.org
Subject: bug#16526: 24.3.50; scroll-conservatively & c-mode regression
Date: Sun, 2 Feb 2014 17:40:50 +0000

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 <at> gmx.at>
> > CC: acm <at> muc.de, 16526 <at> 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).

Previous Next

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