Low redisplay performance (23 regression)

Low redisplay performance (23 regression)

[David Reitter]

I've been noticing a substantial slowdown in redisplay performance.   
Scrolling down emacs.c in fundamental-mode takes about 2 seconds in  
Emacs 22 (Carbon port), and 3 seconds in Emacs 23 (NS port).

With font-lock-mode (in c-mode) enabled, the difference is even larger:

About 2.5 seconds in Emacs 22, and more than 7 seconds in 23/NS.

The effect interacts with the display of overlays etc. in the header  
line.  When turning that off, I get about 2.5 seconds in Emacs 22, and  
still more than 4 seconds in 23/NS.  (All values estimated manually  
from several tries.)

I'm wondering if others get the same on other platforms comparing 22  
and 23, or if this is a problem specifically in the NS port (for  
example, with setting drawing color or the like).

Re: Low redisplay performance (23 regression)

[Deniz Dogan]

2009/4/20 David Reitter <david.reitter@gmail.com>:
> I've been noticing a substantial slowdown in redisplay performance.
>  Scrolling down emacs.c in fundamental-mode takes about 2 seconds in Emacs
> 22 (Carbon port), and 3 seconds in Emacs 23 (NS port).
>
> With font-lock-mode (in c-mode) enabled, the difference is even larger:
>
> About 2.5 seconds in Emacs 22, and more than 7 seconds in 23/NS.
>
> The effect interacts with the display of overlays etc. in the header line.
>  When turning that off, I get about 2.5 seconds in Emacs 22, and still more
> than 4 seconds in 23/NS.  (All values estimated manually from several
> tries.)
>
> I'm wondering if others get the same on other platforms comparing 22 and 23,
> or if this is a problem specifically in the NS port (for example, with
> setting drawing color or the like).

I haven't really done any real testing, but I recall the difference
being quite noticable when I switched from 22 to 23.

--
Deniz Dogan

Re: Low redisplay performance (23 regression)

[Chong Yidong]

David Reitter <david.reitter@gmail.com> writes:

> I'm wondering if others get the same on other platforms comparing 22
> and 23, or if this is a problem specifically in the NS port (for
> example, with setting drawing color or the like).

On GNU/Linux, I do not experience much of a difference in performance
between Emacs 22 and Emacs 23.

If you are trying to track down the problem, you could first try to see
if the problem is occurring in Lisp or in the C code.  For instance,
does scrolling in buffers trigger GCs?  Is there any difference in
performance if you disable the tool-bar or other parts of the graphical
display?

Re: Low redisplay performance (23 regression)

[David Reitter]

[-- Attachment #1: Type: text/plain, Size: 7644 bytes --]

On Apr 20, 2009, at 6:33 PM, Chong Yidong wrote:

> David Reitter <david.reitter@gmail.com> writes:
>
>> I'm wondering if others get the same on other platforms comparing 22
>> and 23, or if this is a problem specifically in the NS port (for
>> example, with setting drawing color or the like).
>
> On GNU/Linux, I do not experience much of a difference in performance
> between Emacs 22 and Emacs 23.
>
> If you are trying to track down the problem, you could first try to  
> see
> if the problem is occurring in Lisp or in the C code.  For instance,
> does scrolling in buffers trigger GCs?  Is there any difference in
> performance if you disable the tool-bar or other parts of the  
> graphical
> display?


I've run Shark over it (profiling tool).
For the Carbon port, it looks uneventful.
For NS /23, I get 24% time spent in mark_object and another 6% in  
garbage_collect.  [Does this indicate consing?]
The 16% in display_mode_lines would support what I observed regarding  
the header line (even though I thought the effect was more than that).

Note that I have (setq redisplay-dont-pause t), because otherwise it  
skips a lot of pages.  Note that it does that too when scrolling line  
by line; for the trace below, I scrolled page-wise.

Regarding display elements: the tool-bar doesn't matter, but the  
header line makes a big difference.  Using a simpler header line (no  
properties, no overlays) improves the speed.  But note that I've used  
the same header line in both Carbon/22 and NS/23.
Unfortunately there doesn't seem to be anything specific about the  
header line that causes the slowdown in NS/23, except that (setq  
header-line-format "Hello") speeds up the scrolling.  But even without  
header line do I see a marked regression compared to 22.



	0.0%	69.2%	Aquamacs	start	
	0.0%	69.2%	Aquamacs	 main	
	0.0%	69.2%	Aquamacs	  Frecursive_edit	
	0.0%	69.2%	Aquamacs	   recursive_edit_1	
	0.0%	69.2%	Aquamacs	    command_loop	
	0.0%	69.2%	Aquamacs	     internal_catch	
	0.0%	69.2%	Aquamacs	      command_loop_2	
	0.0%	69.2%	Aquamacs	       internal_condition_case	
	0.0%	69.2%	Aquamacs	        command_loop_1	
	0.0%	55.9%	Aquamacs	         read_key_sequence	
	0.0%	55.9%	Aquamacs	          read_char	
	0.0%	50.6%	Aquamacs	           redisplay_internal	
	0.0%	38.8%	Aquamacs	            redisplay_windows	
	0.0%	38.8%	Aquamacs	             internal_condition_case_1	
	0.0%	38.8%	Aquamacs	              redisplay_window_0	
	0.0%	38.8%	Aquamacs	               redisplay_window	
	0.0%	17.9%	Aquamacs	                try_window	
	0.1%	17.7%	Aquamacs	                 display_line	
	0.0%	16.2%	Aquamacs	                  get_next_display_element	
	0.1%	16.2%	Aquamacs	                   next_element_from_buffer	
	0.0%	15.5%	Aquamacs	                    handle_stop	
	0.0%	11.5%	Aquamacs	                     handle_fontified_prop	
	0.0%	11.5%	Aquamacs	                      safe_call1	
	0.0%	11.5%	Aquamacs	                       safe_call	
	0.0%	11.5%	Aquamacs	                        internal_condition_case_2	
	0.0%	11.5%	Aquamacs	                         Ffuncall	
	1.4%	6.0%	Aquamacs	                          Fgarbage_collect	
	0.0%	1.3%	Aquamacs	                           lisp_free	
	0.1%	0.7%	libSystem.B.dylib	                            free	
	0.5%	0.6%	libSystem.B.dylib	                             szone_free	
	0.1%	0.1%	libSystem.B.dylib	                               
tiny_free_list_add_ptr	
	0.0%	0.0%	libSystem.B.dylib	                              __spin_lock	
	0.0%	0.0%	libSystem.B.dylib	                               
dyld_stub__spin_lock	
	0.1%	0.1%	libSystem.B.dylib	                             szone_size	
	0.0%	0.0%	libSystem.B.dylib	                              
malloc_zone_free	
	0.5%	0.5%	Aquamacs	                            mem_find	
	0.0%	0.0%	Aquamacs	                            unexec_free	
	0.0%	1.2%	Aquamacs	                           mark_vectorlike	
	0.3%	1.1%	Aquamacs	                           mem_delete	
	0.0%	0.5%	Aquamacs	                           mark_object	
	0.0%	0.3%	Aquamacs	                            
balance_intervals_internal	
	0.1%	0.2%	Aquamacs	                           truncate_undo_list	
	0.0%	0.0%	Aquamacs	                           mark_stack	
	0.0%	0.0%	Aquamacs	                           lisp_align_free	
	0.0%	5.5%	Aquamacs	                          funcall_lambda	
	0.0%	0.0%	Aquamacs	                      Fget_char_property	
	0.0%	3.9%	Aquamacs	                     handle_face_prop	
	0.0%	0.0%	Aquamacs	                     handle_display_prop	
	0.0%	0.0%	Aquamacs	                     handle_invisible_prop	
	0.0%	0.0%	Aquamacs	                     handle_composition_prop	
	0.0%	0.0%	Aquamacs	                     get_overlay_strings	
	0.0%	0.3%	Aquamacs	                    composition_reseat_it	
	0.0%	0.3%	Aquamacs	                    compute_stop_pos	
	0.3%	0.7%	Aquamacs	                  x_produce_glyphs	
	0.0%	0.3%	Aquamacs	                  append_space_for_newline	
	0.1%	0.1%	Aquamacs	                  compute_line_metrics	
	0.0%	0.0%	libSystem.B.dylib	                  __memcpy	
	0.0%	0.0%	Aquamacs	                  handle_line_prefix	
	0.0%	0.0%	Aquamacs	                  set_iterator_to_next	
	0.0%	0.0%	Aquamacs	                  prepare_desired_row	
	0.0%	0.0%	Aquamacs	                  reseat_at_next_visible_line_start	
	0.0%	0.0%	Aquamacs	                  recenter_overlay_lists	
	0.0%	0.0%	Aquamacs	                  get_char_face_and_encoding	
	0.0%	0.1%	Aquamacs	                 start_display	
	0.0%	0.0%	Aquamacs	                 recenter_overlay_lists	
	0.0%	0.0%	Aquamacs	                 init_iterator	
	0.0%	0.0%	Aquamacs	                 append_space_for_newline	
	0.0%	16.1%	Aquamacs	                display_mode_lines	
	0.0%	4.4%	Aquamacs	                update_window_fringes	
	0.0%	0.2%	Aquamacs	                update_frame_tool_bar	
	0.0%	0.1%	Aquamacs	                set_vertical_scroll_bar	
	0.0%	0.0%	Aquamacs	                set_buffer_internal_1	
	0.0%	0.0%	Aquamacs	                reconsider_clip_changes	
	0.0%	10.3%	Aquamacs	            update_frame	
	0.0%	1.5%	Aquamacs	            prepare_menu_bars	
	0.0%	0.0%	Aquamacs	            echo_area_display	
	0.0%	0.0%	Aquamacs	            select_frame_for_redisplay	
	0.0%	0.0%	Aquamacs	            clear_window_matrices	
	0.0%	0.0%	Aquamacs	            clear_desired_matrices	
	0.0%	2.7%	Aquamacs	           sit_for	
	0.0%	1.2%	Aquamacs	           show_help_echo	
	0.0%	0.6%	Aquamacs	           safe_run_hooks	
	0.0%	0.5%	Aquamacs	           wait_reading_process_output	
	0.0%	0.2%	Aquamacs	           detect_input_pending_run_timers	
	0.0%	0.0%	Aquamacs	           read_avail_input	
	0.0%	0.0%	Aquamacs	          follow_key	
	0.0%	10.2%	Aquamacs	         call3	
	0.0%	3.0%	Aquamacs	         safe_run_hooks	
	0.0%	0.0%	Aquamacs	         adjust_point_for_property	
	0.0%	0.0%	Aquamacs	        cmd_error	
	0.0%	24.5%	Aquamacs	mark_object	
	0.0%	4.3%	Aquamacs	mark_vectorlike	
	0.6%	0.7%	mach_kernel	lo_alltraps	
	0.0%	0.5%	mach_kernel	lo_mach_scall	
	0.0%	0.2%	mach_kernel	i386_astintr	
	0.0%	0.1%	Aquamacs	traverse_intervals_noorder	
	0.0%	0.1%	mach_kernel	lo_unix_scall	
	0.0%	0.1%	Aquamacs	mark_buffer	
	0.0%	0.1%	Aquamacs	mark_interval_tree	
	0.0%	0.1%	mach_kernel	thread_continue	
	0.0%	0.0%	mach_kernel	IOWorkLoop::threadMain()	
	0.0%	0.0%	Aquamacs	Frecursive_edit	
	0.0%	0.0%	libSystem.B.dylib	thread_start	
	0.0%	0.0%	mach_kernel	thread_call_enter_delayed	
	0.0%	0.0%	Aquamacs	read_char	
	0.0%	0.0%	mach_kernel	ml_set_interrupts_enabled	
	0.0%	0.0%	mach_kernel	mach_msg_receive_continue	
	0.0%	0.0%	Aquamacs	display_mode_element	


[-- Attachment #2: smime.p7s --]
[-- Type: application/pkcs7-signature, Size: 2193 bytes --]

Re: Low redisplay performance (23 regression)

[Eli Zaretskii]

> From: Chong Yidong <cyd@stupidchicken.com>
> Date: Mon, 20 Apr 2009 18:33:24 -0400
> Cc: Emacs-Devel devel <emacs-devel@gnu.org>
> 
> David Reitter <david.reitter@gmail.com> writes:
> 
> > I'm wondering if others get the same on other platforms comparing 22
> > and 23, or if this is a problem specifically in the NS port (for
> > example, with setting drawing color or the like).
> 
> On GNU/Linux, I do not experience much of a difference in performance
> between Emacs 22 and Emacs 23.

And I see no difference on Windows.

Re: Low redisplay performance (23 regression)

[Juanma Barranquero]

On Tue, Apr 21, 2009 at 05:15, Eli Zaretskii <eliz@gnu.org> wrote:

> And I see no difference on Windows.

I see it. On my setup, doing line-by-line scrolling, Emacs 22.1 is
able to scroll a large file (for example, lisp/ChangeLog) keeping up
with the keyboard typematic rate without breaking a sweat. Emacs 23 is
unable and every now and then resorts to recentering (which I hate).
Thanks to hard work by Chong, it now happens only occasionally,
instead of once every two or three screenfuls; I just witnessed it
five or six times scrolling up to line 2,000 of lisp/ChangeLog.
Fortunately, it's not every day that I scroll hundreds of lines
line-by-line, so it is bearable. But there's no doubt there is a
performance regression with respect to Emacs 22

    Juanma

Re: Low redisplay performance (23 regression)

[David Reitter]

[-- Attachment #1: Type: text/plain, Size: 679 bytes --]

On Apr 21, 2009, at 8:36 AM, Juanma Barranquero wrote:
> instead of once every two or three screenfuls; I just witnessed it
> five or six times scrolling up to line 2,000 of lisp/ChangeLog.
> Fortunately, it's not every day that I scroll hundreds of lines
> line-by-line, so it is bearable. But there's no doubt there is a
> performance regression with respect to Emacs 22

Is this correlated for you with font locking?
Does it happen during page-wise scrolling as well?
(Without redisplay-dont-pause set, it skips a lot of pages for me.)

Let's say the page-wise scrolling performance under NS on my up-to- 
date machine is IMHO unbearable, with font-locking and tabbar enabled.

[-- Attachment #2: smime.p7s --]
[-- Type: application/pkcs7-signature, Size: 2193 bytes --]

Re: Low redisplay performance (23 regression)

[Juanma Barranquero]

On Tue, Apr 21, 2009 at 15:51, David Reitter <david.reitter@gmail.com> wrote:

> Is this correlated for you with font locking?

Only slightly. With font-locking disabled scrolling seems
(subjectively, I've not done any measurement) a bit faster, but I
still see pauses and jumps.

> Does it happen during page-wise scrolling as well?

Page scrolling is quite fast, though I see occasional pauses every now and then.

    Juanma

Re: Low redisplay performance (23 regression)

[William Xu]

David Reitter <david.reitter@gmail.com> writes:

> With font-lock-mode (in c-mode) enabled, the difference is even larger:
>
> About 2.5 seconds in Emacs 22, and more than 7 seconds in 23/NS.

Is my macbook too fast?  With font-lock-mode enabled (23/NS), page
scrolling in buffer emacs.c responds nearly instantly.  I see no delay
at all.


,----[ macbook ]
| - CPU: 2.2 GHz Intel Core 2 Duo
| - Mem: 4 GB 667 MHz DDR2 SDRAM
`----

-- 
William

http://xwl.appspot.com

Re: Low redisplay performance (23 regression)

[David Reitter]

On Apr 21, 2009, at 10:56 AM, William Xu wrote:

> David Reitter <david.reitter@gmail.com> writes:
>
>> With font-lock-mode (in c-mode) enabled, the difference is even  
>> larger:
>>
>> About 2.5 seconds in Emacs 22, and more than 7 seconds in 23/NS.
>
> Is my macbook too fast?  With font-lock-mode enabled (23/NS), page
> scrolling in buffer emacs.c responds nearly instantly.  I see no delay
> at all.

I can't see a delay when scrolling just one page.  The above figures  
are for scrolling page-wise through the whole buffer.

I've tried building with -O9 and tune settings for the CPU - this  
doesn't see to do much.

Re: Low redisplay performance (23 regression)

[Eli Zaretskii]

> From: Juanma Barranquero <lekktu@gmail.com>
> Date: Tue, 21 Apr 2009 14:36:28 +0200
> Cc: david.reitter@gmail.com, Chong Yidong <cyd@stupidchicken.com>,
> 	emacs-devel@gnu.org
> 
> On Tue, Apr 21, 2009 at 05:15, Eli Zaretskii <eliz@gnu.org> wrote:
> 
> > And I see no difference on Windows.
> 
> I see it. On my setup, doing line-by-line scrolling, Emacs 22.1

For the record, I compared with Emacs 22.3.

> is able to scroll a large file (for example, lisp/ChangeLog) keeping up
> with the keyboard typematic rate without breaking a sweat. Emacs 23 is
> unable and every now and then resorts to recentering (which I hate).

Is this in "emacs -Q"?

Anyway, is the slow-down you see close to the OP's reported factor of
almost 3?  Or is it just slow-down?

Re: Low redisplay performance (23 regression)

[Eli Zaretskii]

> Date: Tue, 21 Apr 2009 21:58:21 +0300
> From: Eli Zaretskii <eliz@gnu.org>
> Cc: david.reitter@gmail.com, cyd@stupidchicken.com, emacs-devel@gnu.org
> 
> > is able to scroll a large file (for example, lisp/ChangeLog) keeping up
> > with the keyboard typematic rate without breaking a sweat. Emacs 23 is
> > unable and every now and then resorts to recentering (which I hate).
> 
> Is this in "emacs -Q"?
> 
> Anyway, is the slow-down you see close to the OP's reported factor of
> almost 3?  Or is it just slow-down?

Another idea: could this be somehow related to the fact that your
setup uses UTF-8 as the default encoding?  What happens if you set
your system so that the default is Latin-1, say?

Re: Low redisplay performance (23 regression)

[David Reitter]

[-- Attachment #1: Type: text/plain, Size: 862 bytes --]

On Apr 21, 2009, at 2:58 PM, Eli Zaretskii wrote:
>> is able to scroll a large file (for example, lisp/ChangeLog)  
>> keeping up
>> with the keyboard typematic rate without breaking a sweat. Emacs 23  
>> is
>> unable and every now and then resorts to recentering (which I hate).
>
> Is this in "emacs -Q"?

Not in my case, although I'm using the same setup in 22 and 23.

> Anyway, is the slow-down you see close to the OP's reported factor of
> almost 3?  Or is it just slow-down?

Note that the most dramatic changes are due to my header line (tabbar)  
and also face remapping:

(setq face-remapping-alist nil header-line-format nil)

(NB, I have backported the face remapping functionality to 22, so I  
believe am comparing like for like.)

Without face-remapping and header line, I estimate the slowdown is  
about 20% for me, a noticeable difference.



[-- Attachment #2: smime.p7s --]
[-- Type: application/pkcs7-signature, Size: 2193 bytes --]

Re: Low redisplay performance (23 regression)

[Chong Yidong]

David Reitter <david.reitter@gmail.com> writes:

> Without face-remapping and header line, I estimate the slowdown is
> about 20% for me, a noticeable difference.

Try something for me:

  M-: (setq mode-line-format "") RET

This removes everything from the mode-line.  Does it make any
difference?

Re: Low redisplay performance (23 regression)

[David Reitter]

[-- Attachment #1: Type: text/plain, Size: 964 bytes --]

On Apr 21, 2009, at 4:53 PM, Chong Yidong wrote:

> David Reitter <david.reitter@gmail.com> writes:
>
>> Without face-remapping and header line, I estimate the slowdown is
>> about 20% for me, a noticeable difference.
>
> Try something for me:
>
>  M-: (setq mode-line-format "") RET
>
> This removes everything from the mode-line.  Does it make any
> difference?

I tried (setq mode-line-format) and it doesn't make a noticeable  
difference.

I also tried (setq header-line-format "Hello"), which was reasonably  
fast.

Removing various face properties set for parts of the header line  
seems to make it go faster.

To recap, removing the more diverse face settings in face-remapping- 
alist helps, too.  Also, removing font-locking helps.

Given the evidence, I wonder

1. Is the header line is drawn more often than it should? (scrolling  
shouldn't redraw it).
2. Does changing / setting / finding faces now incur more of a penalty  
now compared to 22.3?


[-- Attachment #2: smime.p7s --]
[-- Type: application/pkcs7-signature, Size: 2193 bytes --]

Re: Low redisplay performance (23 regression)

[Juanma Barranquero]

On Tue, Apr 21, 2009 at 20:58, Eli Zaretskii <eliz@gnu.org> wrote:

> For the record, I compared with Emacs 22.3.

Last time I tested, Emacs 22.3 (or EMACS_22_BASE) was as fast as 22.1.

> Is this in "emacs -Q"?

Yes. Emacs -Q, and then

(setq scroll-preserve-screen-position 'always
      scroll-conservatively           most-positive-fixnum
      scroll-step                     0

> Anyway, is the slow-down you see close to the OP's reported factor of
> almost 3?  Or is it just slow-down?

No. As I said, it is somewhat slower than 22.3, but it is adequate.

    Juanma

Re: Low redisplay performance (23 regression)

[Juanma Barranquero]

On Tue, Apr 21, 2009 at 21:07, Eli Zaretskii <eliz@gnu.org> wrote:

> Another idea: could this be somehow related to the fact that your
> setup uses UTF-8 as the default encoding?  What happens if you set
> your system so that the default is Latin-1, say?

I set UTF-8 in my init.el, not the environment. With Emacs -Q I'm
letting Emacs choose language environment:

 current-language-environment => "Spanish"

 C-h C <RET>

Coding system for saving this buffer:
  Not set locally, use the default.
Default coding system (for new files):
  1 -- iso-latin-1-dos (alias: iso-8859-1-dos latin-1-dos)

Coding system for keyboard input:
  = -- no-conversion (alias: binary)

Coding system for terminal output:
  nil
Coding system for inter-client cut and paste:
  U -- utf-16le-dos

Defaults for subprocess I/O:
  decoding: - -- undecided-dos (alias: dos)

  encoding: - -- undecided-unix (alias: unix)


Priority order for recognizing coding systems when reading files:
  1. iso-latin-1 (alias: iso-8859-1 latin-1)
  2. utf-8 (alias: mule-utf-8)
  3. iso-2022-7bit
  4. iso-2022-7bit-lock (alias: iso-2022-int-1)
  5. iso-2022-8bit-ss2
  6. emacs-mule
  7. raw-text
  8. iso-2022-jp (alias: junet)
  9. in-is13194-devanagari (alias: devanagari)
  10. chinese-iso-8bit (alias: cn-gb-2312 euc-china euc-cn cn-gb gb2312)
  11. utf-8-auto
  12. utf-8-with-signature
  13. utf-16
  14. utf-16be-with-signature (alias: utf-16-be)
  15. utf-16le-with-signature (alias: utf-16-le)
  16. utf-16be
  17. utf-16le
  18. japanese-shift-jis (alias: shift_jis sjis)
  19. chinese-big5 (alias: big5 cn-big5 cp950)
  20. undecided

etc.

    Juanma

Re: Low redisplay performance (23 regression)

[William Xu]

David Reitter <david.reitter@gmail.com> writes:

>> Is my macbook too fast?  With font-lock-mode enabled (23/NS), page
>> scrolling in buffer emacs.c responds nearly instantly.  I see no delay
>> at all.
>
> I can't see a delay when scrolling just one page.  The above figures are for
> scrolling page-wise through the whole buffer.

Hmm.. Does "page-wise" scrolling means keeping pressing C-v (or,
scroll-up) until the end of the buffer? Works well for me too...   


-- 
William

http://xwl.appspot.com

Re: Low redisplay performance (23 regression)

[Daniel Clemente]

  I haven't compared Emacs 22 and 23, but from a subjective point of view I have noticed that latest Emacs 23 feels slow and updates too much for a modern computer. Some particular problems I noticed randomly:

 - if I hold C-n, I don't see the cursor while it is moving down; I only see it jump when I have released the key. C-p works faster. This happened when I had lots of CEDET buffers open (not even parsing)

 - just switching to an Emacs frame (from another window in the window manager) paints the screen progressively; this happens in tenths of second but so slowly that you can track the updated zone while it moves from top to bottom. This can be due to the video driver, X, window manager, …

 - sometimes, the buffer is updated noticeably two times in succession; this happened with org-mode files (latest org-mode from Git). This could also be from Org.


>
> Note that the most dramatic changes are due to my header line (tabbar) and also
> face remapping:
>

  Note that tabbar lowers the performance by a large factor. It seems the function tabbar-buffer-update-groups is run after each keypress which involves a movement on the buffer, a buffer change or a message.
  Try to disable it temporarily. The problem of the visually lost C-n went away when I turned it off.
  To test how much it is called, something like this can be useful:

(defadvice tabbar-buffer-update-groups (before beep-whenever-you-redisplay-buffers activate)
(shell-command "beep -l 50")
)



-- Daniel

Re: Low redisplay performance (23 regression)

[David Reitter]

On Apr 22, 2009, at 11:30 AM, Daniel Clemente wrote:

>  I haven't compared Emacs 22 and 23, but from a subjective point of  
> view I have noticed that latest Emacs 23 feels slow and updates too  
> much for a modern computer. Some particular problems I noticed  
> randomly:
>
> - if I hold C-n, I don't see the cursor while it is moving down; I  
> only see it jump when I have released the key. C-p works faster.  
> This happened when I had lots of CEDET buffers open (not even parsing)
>
> - just switching to an Emacs frame (from another window in the  
> window manager) paints the screen progressively; this happens in  
> tenths of second but so slowly that you can track the updated zone  
> while it moves from top to bottom. This can be due to the video  
> driver, X, window manager, …
>
> - sometimes, the buffer is updated noticeably two times in  
> succession; this happened with org-mode files (latest org-mode from  
> Git). This could also be from Org.

I can corroborate these observations (subjectively FWIW) with  
different modes such as SLIME and on NS (on OS X).  So I don't think  
it's anything system-related (drivers, X, etc).

>  Note that tabbar lowers the performance by a large factor. It seems  
> the function tabbar-buffer-update-groups is run after each keypress  
> which involves a movement on the buffer, a buffer change or a message.
>  Try to disable it temporarily. The problem of the visually lost C-n  
> went away when I turned it off.
>  To test how much it is called, something like this can be useful:

Thanks, but I don't use tabbar in this way (my branch is found here:  
[1]), so this function doesn't get called.

Note that if I run tabbar, but just set header-line-format to  
something simpler (without all those faces), then I get a substantial  
speedup.


However, the point here is that these slowdowns with tabbar, SLIME,  
org-mode and whatever did not occur in Emacs 22.  This is going to be  
bad for any user.




[1] git://github.com/davidswelt/aquamacs-emacs.git

Re: Low redisplay performance (23 regression)

[Chong Yidong]

David Reitter <david.reitter@gmail.com> writes:

> I can corroborate these observations (subjectively FWIW) with
> different modes such as SLIME and on NS (on OS X).  So I don't think
> it's anything system-related (drivers, X, etc).
>
> Note that if I run tabbar, but just set header-line-format to
> something simpler (without all those faces), then I get a substantial
> speedup.

So, the slowdown may be related to displaying multiple faces?  I have
not experienced anything like this, myself.  If you do M-x
list-faces-display and scroll through that buffer, is there a slowdown?

It's possible that tabbar is doing something with its face computation
that is much more expensive on Emacs 23 than on Emacs 22; I don't have
time to look at its code, however.

Re: Low redisplay performance (23 regression)

[David Reitter]

On Apr 22, 2009, at 12:28 PM, Chong Yidong wrote:
> So, the slowdown may be related to displaying multiple faces?  I have
> not experienced anything like this, myself.  If you do M-x
> list-faces-display and scroll through that buffer, is there a  
> slowdown?

Yes, definitely, but if and only if face-remapping-alist is enabled  
(remapping the default face).
With the tabbar enabled, scrolling down that buffer takes about twice  
as long, depending on how many tabs I show.
Without the tabbar, I estimate the slowdown is about 20-30%.

> It's possible that tabbar is doing something with its face computation
> that is much more expensive on Emacs 23 than on Emacs 22; I don't have
> time to look at its code, however.


As above, it's not just the tabbar; doing something relatively simple  
with face-remapping-alist already shows the effect.

I've been working on coming up with a reproducible standalone  
example.  Perhaps, if the others who can reproduce, could attempt the  
same, we'd get somewhere.

Re: Low redisplay performance (23 regression)

[YAMAMOTO Mitsuharu]

>>>>> On Wed, 22 Apr 2009 17:30:37 +0200, Daniel Clemente <dcl441-bugs@yahoo.com> said:

>   I haven't compared Emacs 22 and 23, but from a subjective point of
> view I have noticed that latest Emacs 23 feels slow and updates too
> much for a modern computer. Some particular problems I noticed
> randomly:

Which font backend driver are you using?  You can check it with (cdr
(assq 'font-backend (frame-parameters))).  I found the ftx font driver
was much slower than the xft one partly because of repeated
calculations of font metrics.  (So I added some cache code to
ftcrfont.c in my latest cairo patch posted here).

				     YAMAMOTO Mitsuharu
				mituharu@math.s.chiba-u.ac.jp

ftx font driver [Re: Low redisplay performance (23 regression)]

[Kenichi Handa]

In article <wlzle8i9cf.wl%mituharu@math.s.chiba-u.ac.jp>, YAMAMOTO Mitsuharu <mituharu@math.s.chiba-u.ac.jp> writes:

>>>>>> On Wed, 22 Apr 2009 17:30:37 +0200, Daniel Clemente <dcl441-bugs@yahoo.com> said:
> >   I haven't compared Emacs 22 and 23, but from a subjective point of
> > view I have noticed that latest Emacs 23 feels slow and updates too
> > much for a modern computer. Some particular problems I noticed
> > randomly:

> Which font backend driver are you using?  You can check it with (cdr
> (assq 'font-backend (frame-parameters))).  I found the ftx font driver
> was much slower than the xft one partly because of repeated
> calculations of font metrics.  (So I added some cache code to
> ftcrfont.c in my latest cairo patch posted here).

Please exlain why it calculates font metrics repeatedly.

As ftx font driver is not used by default on any platforms,
it is not tested well and I myself don't remember the code
well.

---
Kenichi Handa
handa@m17n.org

Re: ftx font driver [Re: Low redisplay performance (23 regression)]

[YAMAMOTO Mitsuharu]

>>>>> On Thu, 23 Apr 2009 10:01:12 +0900, Kenichi Handa <handa@m17n.org> said:

>>> I haven't compared Emacs 22 and 23, but from a subjective point of
>>> view I have noticed that latest Emacs 23 feels slow and updates
>>> too much for a modern computer. Some particular problems I noticed
>>> randomly:

>> Which font backend driver are you using?  You can check it with
>> (cdr (assq 'font-backend (frame-parameters))).  I found the ftx
>> font driver was much slower than the xft one partly because of
>> repeated calculations of font metrics.  (So I added some cache code
>> to ftcrfont.c in my latest cairo patch posted here).

> Please exlain why it calculates font metrics repeatedly.

> As ftx font driver is not used by default on any platforms, it is
> not tested well and I myself don't remember the code well.

There might be the case that the Xft library is not installed, does
not have a sufficient version, or not found by configure for some
reasons (e.g., PKG_CONFIG_PATH is not set appropriately).  In such
cases, the ftx font driver is selected as a default.  Of course, you
can reproduce such a situation with --without-xft.

The result of time profiling using Shark.app indicates that
FT_Load_Glyph called from ftfont_text_extents takes much time and
calculates font metrics repeatedly without caching.  In particular,
it's really slow if the font is actually in a gzipped PCF format.

				     YAMAMOTO Mitsuharu
				mituharu@math.s.chiba-u.ac.jp

	0.0%	99.7%	emacs	start	
	0.0%	99.7%	emacs	 main	
	0.0%	99.7%	emacs	  Frecursive_edit	
	0.0%	99.7%	emacs	   recursive_edit_1	
	0.0%	99.7%	emacs	    command_loop	
	0.0%	99.7%	emacs	     internal_catch	
	0.0%	99.7%	emacs	      command_loop_2	
	0.0%	99.7%	emacs	       internal_condition_case	
	0.0%	99.7%	emacs	        command_loop_1	
	0.0%	79.4%	emacs	         call3	
	0.0%	79.4%	emacs	          Ffuncall	
	0.0%	79.4%	emacs	           Fcall_interactively	
	0.0%	79.4%	emacs	            Ffuncall	
	0.0%	69.9%	emacs	             Fscroll_down	
	0.0%	69.9%	emacs	              scroll_command	
	0.0%	69.9%	emacs	               window_scroll	
	0.0%	25.1%	emacs	                pos_visible_p	
	0.0%	22.4%	emacs	                 move_it_to	
	0.0%	22.4%	emacs	                  move_it_in_display_line_to	
	0.0%	22.3%	emacs	                   x_produce_glyphs	
	0.0%	22.2%	emacs	                    get_per_char_metric	
	0.0%	22.2%	emacs	                     ftfont_text_extents	
	0.0%	22.2%	libfreetype.6.dylib	                      FT_Load_Glyph	
	0.1%	22.0%	libfreetype.6.dylib	                       PCF_Glyph_Load	
	0.0%	21.8%	libfreetype.6.dylib	                        FT_Stream_Seek	
	0.0%	21.8%	libfreetype.6.dylib	                         ft_gzip_stream_io	
	0.0%	21.8%	libfreetype.6.dylib	                          ft_gzip_file_io	
	0.0%	21.8%	libfreetype.6.dylib	                           ft_gzip_file_skip_output	
	21.3%	21.8%	libfreetype.6.dylib	                            ft_gzip_file_fill_output	
	0.5%	0.5%	libfreetype.6.dylib	                             ft_gzip_file_fill_input	
	0.0%	0.1%	libfreetype.6.dylib	                        ft_glyphslot_alloc_bitmap	
	0.0%	0.1%	libfreetype.6.dylib	                        FT_Stream_Read	
	0.0%	0.1%	libfreetype.6.dylib	                       ft_glyphslot_clear	
	0.0%	0.1%	emacs	                    get_char_face_and_encoding	
	0.0%	0.0%	emacs	                    get_it_property	
	0.0%	0.0%	emacs	                   get_next_display_element	
	0.0%	0.0%	emacs	                   set_iterator_to_next	
	0.0%	2.1%	emacs	                 display_mode_line	
	0.0%	0.7%	emacs	                 line_bottom_y	
	0.0%	22.5%	emacs	                move_it_to	
	0.0%	22.5%	emacs	                 move_it_in_display_line_to	
	0.0%	22.4%	emacs	                  x_produce_glyphs	
	0.0%	22.3%	emacs	                   get_per_char_metric	
	0.0%	22.3%	emacs	                    ftfont_text_extents	
	0.0%	22.3%	libfreetype.6.dylib	                     FT_Load_Glyph	
	0.0%	22.2%	libfreetype.6.dylib	                      PCF_Glyph_Load	
	0.0%	22.0%	libfreetype.6.dylib	                       FT_Stream_Seek	
	0.0%	22.0%	libfreetype.6.dylib	                        ft_gzip_stream_io	
	0.0%	22.0%	libfreetype.6.dylib	                         ft_gzip_file_io	
	0.0%	21.9%	libfreetype.6.dylib	                          ft_gzip_file_skip_output	
	21.5%	21.9%	libfreetype.6.dylib	                           ft_gzip_file_fill_output	
	0.0%	0.0%	libfreetype.6.dylib	                          ft_gzip_file_reset	
	0.0%	0.1%	libfreetype.6.dylib	                       FT_Stream_Read	
	0.0%	0.1%	libfreetype.6.dylib	                       ft_glyphslot_alloc_bitmap	
	0.0%	0.0%	libfreetype.6.dylib	                       ft_synthesize_vertical_metrics	
	0.0%	0.1%	libfreetype.6.dylib	                      ft_glyphslot_clear	
	0.0%	0.1%	emacs	                   get_char_face_and_encoding	
	0.0%	0.0%	emacs	                   get_it_property	
	0.0%	0.1%	emacs	                  get_next_display_element	
	0.0%	0.0%	emacs	                  set_iterator_to_next	
	0.0%	0.0%	emacs	                 recenter_overlay_lists	
	0.0%	21.7%	emacs	                move_it_vertically_backward	
	0.0%	0.6%	emacs	                move_it_by_lines	
	0.0%	9.5%	emacs	             Fscroll_up	
	0.0%	20.3%	emacs	         read_key_sequence	
	0.0%	0.0%	emacs	         resize_echo_area_exactly	
	0.0%	0.0%	emacs	         start_hourglass	
	0.0%	0.0%	emacs	         safe_run_hooks	
	0.0%	0.0%	emacs	         Fcommand_remapping	
	0.1%	0.1%	mach_kernel	lo_alltraps	
	0.0%	0.1%	mach_kernel	lo_mach_scall	
	0.0%	0.0%	mach_kernel	lo_unix_scall	
	0.0%	0.0%	mach_kernel	i386_astintr	
	0.0%	0.0%	mach_kernel	IOWorkLoop::threadMain()	
	0.0%	0.0%	mach_kernel	thread_call_enter_delayed	
	0.0%	0.0%	mach_kernel	uiomove	

Re: ftx font driver [Re: Low redisplay performance (23 regression)]

[Kenichi Handa]

In article <wlvdov9673.wl%mituharu@math.s.chiba-u.ac.jp>, YAMAMOTO Mitsuharu <mituharu@math.s.chiba-u.ac.jp> writes:

> > As ftx font driver is not used by default on any platforms, it is
> > not tested well and I myself don't remember the code well.

> There might be the case that the Xft library is not installed, does
> not have a sufficient version, or not found by configure for some
> reasons (e.g., PKG_CONFIG_PATH is not set appropriately).  In such
> cases, the ftx font driver is selected as a default.  Of course, you
> can reproduce such a situation with --without-xft.

Ah, you are right.  I should have written "usually" instead
of "by default". 

> The result of time profiling using Shark.app indicates that
> FT_Load_Glyph called from ftfont_text_extents takes much time and
> calculates font metrics repeatedly without caching.  In particular,
> it's really slow if the font is actually in a gzipped PCF format.

[...]
> 	0.0%	22.2%        FT_Load_Glyph	
> 	0.1%	22.0%         PCF_Glyph_Load	
> 	0.0%	21.8%          FT_Stream_Seek	
> 	0.0%	21.8%           ft_gzip_stream_io	
> 	0.0%	21.8%            ft_gzip_file_io	
> 	0.0%	21.8%             ft_gzip_file_skip_output	
> 	21.3%	21.8%              ft_gzip_file_fill_output	
> 	0.5%	0.5%                ft_gzip_file_fill_input	

Ummm, I didn't realize this calling sequence.  I agree that
we surely need some kind of caching mechanism.  But, it
seems that FreeType itself has that mechanism called "Cache
Sub-System".  Perhaps, we should use it.

---
Kenichi Handa
handa@m17n.org

Re: ftx font driver [Re: Low redisplay performance (23 regression)]

[Chong Yidong]

Kenichi Handa <handa@m17n.org> writes:

> Ummm, I didn't realize this calling sequence.  I agree that
> we surely need some kind of caching mechanism.  But, it
> seems that FreeType itself has that mechanism called "Cache
> Sub-System".  Perhaps, we should use it.

Unless this is extremely simple to implement, let's leave this for after
the release.

Maybe we should add a warning message to configure that marks the ftx
backend as experimental; i.e., telling people that they should build
--without-freetype if libxft is unavailable.

Re: Low redisplay performance (23 regression)

[Willem Rein Oudshoorn]

Maybe related, but what I noticed is that when I do:

emacs -Q

M-x list-charset-chars
    mule-unicode-0100-24ff

scrolling in the resulting buffer is extremely slow.  
PgUp PgDn, C-n C-p will eat up 100% and it is very jerky.

This is both on mswindows and Mac OS X.  

Mac OS X:
GNU Emacs 23.0.60.5 (i386-apple-darwin9.5.0, NS apple-appkit-949.35) of 2009-01-06 on Silver-2.local

MS Windows:
23.0.60.1 2009-01-01 on LENNART-69DE564 (patched)

Kind regards,
Wim Oudshoorn

Re: ftx font driver [Re: Low redisplay performance (23 regression)]

[Stefan Monnier]

>> Ummm, I didn't realize this calling sequence.  I agree that
>> we surely need some kind of caching mechanism.  But, it
>> seems that FreeType itself has that mechanism called "Cache
>> Sub-System".  Perhaps, we should use it.

> Unless this is extremely simple to implement, let's leave this for after
> the release.

> Maybe we should add a warning message to configure that marks the ftx
> backend as experimental; i.e., telling people that they should build
> --without-freetype if libxft is unavailable.

Could someone describe the purpose of the ftx backend?  Obviously,
someone went to the trouble to write it, so there must have been some
reason why we want to support it, but from what I read above, I get the
impression that nowadays e could just scrap it altogether since xft
works better.


        Stefan

Re: Low redisplay performance (23 regression)

[Miles Bader]

Willem Rein Oudshoorn <woudshoo@xs4all.nl> writes:
> M-x list-charset-chars
>     mule-unicode-0100-24ff
>
> scrolling in the resulting buffer is extremely slow.  
> PgUp PgDn, C-n C-p will eat up 100% and it is very jerky.
>
> This is both on mswindows and Mac OS X.  

Have you tried doing it (scrolling through the buffer) _twice_?

On debian, paging through the buffer the first time through is pretty
slow, presumably because it's rendering tons of new characters on every
page, but if I go back and do it again it's very fast (not perceptibly
different than pages full of normal text).  I assume there must be a
fair-amount of caching going on...

-Miles

-- 
Saa, shall we dance?  (from a dance-class advertisement)

Re: ftx font driver [Re: Low redisplay performance (23 regression)]

[Kenichi Handa]

In article <jwvk55be7y4.fsf-monnier+emacs@gnu.org>, Stefan Monnier <monnier@iro.umontreal.ca> writes:

> Could someone describe the purpose of the ftx backend?  Obviously,
> someone went to the trouble to write it, so there must have been some
> reason why we want to support it, but from what I read above, I get the
> impression that nowadays e could just scrap it altogether since xft
> works better.

I wrote ftx backend before writing xft backend because the
documentation of Xft library was poor (even now so) and it
was easier to debug the font-backend mechanism with ftx
backend (because it directly uses freetype).

I don't know how many systems have X but not Xft, but if
there exists such a system, ftx backend is still necessary.

---
Kenichi Handa
handa@m17n.org

Re: ftx font driver [Re: Low redisplay performance (23 regression)]

[Stefan Monnier]

> I don't know how many systems have X but not Xft, but if
> there exists such a system, ftx backend is still necessary.

You mean

   I don't know how many systems have X and freetype but not Xft, but if
   there exists such a system, ftx backend is still useful.

I think it's perfectly OK to say "if you have X and freetype, either
install xft, or live without anti-aliasing".  IIUC that means I'd get
rid of the ftx backend.


        Stefan

Re: ftx font driver [Re: Low redisplay performance (23 regression)]

[Chong Yidong]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

> I think it's perfectly OK to say "if you have X and freetype, either
> install xft, or live without anti-aliasing".  IIUC that means I'd get
> rid of the ftx backend.

How bout the following?  (It should be fairly safe.)

*** trunk/configure.in.~1.591.~	2009-04-19 21:34:45.000000000 -0400
--- trunk/configure.in	2009-04-23 23:43:54.000000000 -0400
***************
*** 133,139 ****
  OPTION_DEFAULT_ON([png],[don't compile with PNG image support])
  OPTION_DEFAULT_ON([rsvg],[don't compile with SVG image support])
  
- OPTION_DEFAULT_ON([freetype],[don't use Freetype for local font support])
  OPTION_DEFAULT_ON([xft],[don't use XFT for anti aliased fonts])
  OPTION_DEFAULT_ON([libotf],[don't use libotf for OpenType font support])
  OPTION_DEFAULT_ON([m17n-flt],[don't use m17n-flt for text shaping])
--- 133,138 ----
***************
*** 1270,1276 ****
  if test "${HAVE_NS}" = yes; then
    window_system=nextstep
    with_xft=no
-   with_freetype=no
    # set up packaging dirs
    exec_prefix=${ns_appbindir}
    libexecdir=${ns_appbindir}/libexec
--- 1269,1274 ----
***************
*** 1844,1854 ****
  ### Start of font-backend (under X11) section.
  if test "${HAVE_X11}" = "yes"; then
     PKG_CHECK_MODULES(FONTCONFIG, fontconfig >= 2.2.0, HAVE_FC=yes, HAVE_FC=no)
-    test "${HAVE_FC}" = "no" && with_freetype=no
  
! ## Use -lXft if available, unless `--with-freetype=no' nor `--with-xft=no'.
     HAVE_XFT=maybe
!     if test "x${with_freetype}" = "xno" || test "x${with_x}" = "xno"; then
        with_xft="no";
      fi
      if test "x${with_xft}" != "xno"; then
--- 1842,1851 ----
  ### Start of font-backend (under X11) section.
  if test "${HAVE_X11}" = "yes"; then
     PKG_CHECK_MODULES(FONTCONFIG, fontconfig >= 2.2.0, HAVE_FC=yes, HAVE_FC=no)
  
!    ## Use -lXft if available, unless `--with-xft=no'.
     HAVE_XFT=maybe
!     if test "${HAVE_FC}" = "no" || test "x${with_x}" = "xno"; then
        with_xft="no";
      fi
      if test "x${with_xft}" != "xno"; then
***************
*** 1890,1898 ****
        HAVE_FREETYPE=yes
        FONTCONFIG_CFLAGS=
        FONTCONFIG_LIBS=
-     elif test "x${with_freetype}" != "xno" && test "x${with_x}" != "xno"; then
- 
-       PKG_CHECK_MODULES(FREETYPE, freetype2, HAVE_FREETYPE=yes, HAVE_FREETYPE=no)
      fi
  
      HAVE_LIBOTF=no
--- 1887,1892 ----

Re: ftx font driver [Re: Low redisplay performance (23 regression)]

[Chong Yidong]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

> I think it's perfectly OK to say "if you have X and freetype, either
> install xft, or live without anti-aliasing".  IIUC that means I'd get
> rid of the ftx backend.

I have checked in the previously-posted patch to configure.in.  This
disables the use of freetype if xft is not used.  I have not touched the
actualy ftx driver code, however; we can decide what to do about it
after the release.

Re: Low redisplay performance (23 regression)

[Tobias C. Rittweiler]

David Reitter <david.reitter@gmail.com> writes:

> [Emacs 23.x performance regression]

On a related note, I notice a big slowdown for `end-of-defun'.

In a .lisp buffer with 6371 lines, running the following

  (benchmark-run
   (dotimes (i 100)
     (beginning-of-buffer)
     (dotimes (i 200)
       (end-of-defun))))

yields the folloing timings:

  GNU Emacs 22.1.1     -->  (4.323907 2 0.07007399999999997)
  GNU Emacs 23.0.60.1  -->  (7.5862680000000005 1 0.048462000000000005)
  GNU Emacs 23.0.92.1  -->  (7.610763 2 0.06742599999999999)
  (built on 2009-04-29)

As I use `end-of-defun' in my customized
`font-lock-extend-region-functions' this does have an impact on the
overall performance of fontification for me on large files.

What is the reason that `end-of-defun' is an _order of magnitude_ slower
than `beginning-of-defun'?

  -T.

Re: Low redisplay performance (23 regression)

[David Reitter]

On Apr 29, 2009, at 6:17 AM, Tobias C. Rittweiler wrote:
>
> On a related note, I notice a big slowdown for `end-of-defun'.

I noticed that part of my problem was due to garbage collection, so  
you might want to exclude that.  (The real reason why GC occurs so  
often hasn't been investigated yet.)

Re: Low redisplay performance (23 regression)

[Stefan Monnier]

>   GNU Emacs 22.1.1     -->  (4.323907 2 0.07007399999999997)
>   GNU Emacs 23.0.60.1  -->  (7.5862680000000005 1 0.048462000000000005)
>   GNU Emacs 23.0.92.1  -->  (7.610763 2 0.06742599999999999)
>   (built on 2009-04-29)

So it's about twice as slow for this test, which is the expected in this
case: since your benchmark always calls it with point between 2 defuns,
it ends up doing: BOD-raw to find the previous defun, EOD-function to
find its end, which tells Emacs that the starting point was after the
previous defun, so it calls BOD-raw again to find the next defun and
finally EOD-function to get to its end.

> As I use `end-of-defun' in my customized
> `font-lock-extend-region-functions' this does have an impact on the
> overall performance of fontification for me on large files.

I don't think the size of the file (aka buffer) should make
a difference.  And I can't think of a good reason why EOD should take
a non-negligible amount of time compared to running
font-lock-fontify-region on a whole defun at a time.

> What is the reason that `end-of-defun' is an _order of magnitude_ slower
> than `beginning-of-defun'?

Because EOD uses BOD internally, I guess.  Of course in your
font-lock-extend-region-functions, you may simply prefer to use BOD
rather than EOD.


        Stefan

Re: Low redisplay performance (23 regression)

[Tobias C. Rittweiler]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

> > As I use `end-of-defun' in my customized
> > `font-lock-extend-region-functions' this does have an impact on the
> > overall performance of fontification for me on large files.
>
> I don't think the size of the file (aka buffer) should make
> a difference.  

Yes, I meant to write on large defuns. I test this on a file which
contains defuns spanning up to 500-600 lines.


> And I can't think of a good reason why EOD should take a
> non-negligible amount of time compared to running
> font-lock-fontify-region on a whole defun at a time.

Find the below profiling outputs. The first is for Emacs 22.1.1, the
second for 23.0.92.1 (checked out, and built today.)

I used `elp' to do the profiling. I profiled the slime package, the
font-lock package, and the jit-lock package. As well as
`beginning-of-defun', `beginning-of-defun-raw', and `end-of-defun'.

Then I open a file, and scroll down to the end using Page Down.

(`slime-extend-region-for-defun' is a font-lock extend-region function
which calls `slime-region-for-extended tlf-at-point' which in turns call
`slime-region-for-tlf-at-point' which calls `end-of-defun' once, and
`beginning-of-defun' several times. `slime-search-suppressed-forms' is a
marker function on `font-lock-keywords'.)

You'll see in the profiling output that basically all functions run
slower on 23.x. It's still fast enough except for the extreme cases of
defuns spanning over 500 lines.

I'm not sure how much you can do with this information. But I can concur
with the OP that there does seem to be a performance regression.

  -T.

PS.

GNU Emacs 22.1.1

Function Name                                              Call Count  Elapsed Time  Average Time
=========================================================  ==========  ============  ============
jit-lock-function                                          478         6.0523169999  0.0126617510
jit-lock-fontify-now                                       478         6.0471380000  0.0126509163
font-lock-fontify-region                                   478         5.9743459999  0.0124986317
font-lock-default-fontify-region                           478         5.9653550000  0.0124798221
slime-extend-region-for-font-lock                          954         2.8670120000  0.0030052536
font-lock-fontify-keywords-region                          478         2.2039999999  0.0046108786
slime-region-for-tlf-at-point                              924         1.9189019999  0.0020767337
end-of-defun                                               1848        1.6501459999  0.0008929361
slime-region-for-extended-tlf-at-point                     461         1.213281      0.0026318459
slime-search-suppressed-forms                              922         1.0144610000  0.0011002830
font-lock-fontify-syntactically-region                     478         0.747676      0.0015641757
beginning-of-defun-raw                                     4233        0.5864199999  0.0001385353
beginning-of-defun                                         2382        0.5515089999  0.0002315319
slime-forward-sexp                                         220         0.0974470000  0.0004429409
slime-forward-cruft                                        220         0.0939059999  0.0004268454
slime-eval-feature-conditional                             444         0.0917369999  0.0002066148
slime-lisp-features                                        444         0.0813829999  0.0001832950
slime-forward-blanks                                       220         0.0522439999  0.0002374727
font-lock-extend-region-wholelines                         954         0.0449930000  4.716...e-05
slime-forward-any-comment                                  220         0.0356580000  0.0001620818
font-lock-unfontify-region                                 478         0.0288390000  6.033...e-05
font-lock-default-unfontify-region                         478         0.0204609999  4.280...e-05
slime-pre-command-hook                                     106         0.0053909999  5.085...e-05
slime-connection                                           444         0.0053260000  1.199...e-05
font-lock-extend-region-multiline                          954         0.0042749999  4.481...e-06
slime-keywordify                                           444         0.0030740000  6.923...e-06
slime-connected-p                                          922         0.0023909999  2.593...e-06
font-lock-set-defaults                                     484         0.0016050000  3.316...e-06
jit-lock-context-fontify                                   7           0.0012900000  0.0001842857
slime-forward-reader-conditional                           220         0.0011560000  5.254...e-06
slime-current-connection                                   444         0.0010020000  2.256...e-06
font-lock-mode                                             8           0.0009860000  0.0001232500
font-lock-default-function                                 8           0.0007859999  9.824...e-05
font-lock-mode-internal                                    2           0.000696      0.000348
slime-post-command-hook                                    106         0.0006859999  6.471...e-06
font-lock-turn-on-thing-lock                               2           0.000424      0.000212
jit-lock-register                                          2           0.0003670000  0.0001835000
jit-lock-mode                                              2           0.000339      0.0001695
jit-lock-refontify                                         2           0.0003019999  0.0001509999
font-lock-compile-keywords                                 2           0.000188      9.4e-05
slime-lisp-mode-hook                                       1           7.9e-05       7.9e-05
font-lock-compile-keyword                                  32          6.7e-05       2.09375e-06
slime-mode                                                 1           6.3e-05       6.3e-05
font-lock-change-mode                                      1           5.3e-05       5.3e-05
font-lock-add-keywords                                     2           4.6e-05       2.3e-05
slime-setup-command-hooks                                  1           3.4e-05       3.4e-05
slime-add-local-hook                                       2           2.100...e-05  1.050...e-05
font-lock-remove-keywords                                  2           2.100...e-05  1.050...e-05
font-lock-value-in-major-mode                              5           1.1e-05       2.2e-06
font-lock-eval-keywords                                    2           9e-06         4.5e-06
slime-setup-first-change-hook                              1           5e-06         5e-06
slime-add-easy-menu                                        1           4e-06         4e-06
font-lock-choose-keywords                                  1           3e-06         3e-06


------------------------------------------------------------

GNU Emacs 23.0.92.1

jit-lock-function                                          478         9.4705599999  0.0198128870
jit-lock-fontify-now                                       478         9.4663009999  0.0198039769
font-lock-fontify-region                                   478         9.4454880000  0.0197604351
font-lock-default-fontify-region                           478         9.4372980000  0.0197433012
font-lock-fontify-keywords-region                          478         4.463293      0.0093374330
slime-extend-region-for-font-lock                          954         3.9002370000  0.0040882987
slime-region-for-tlf-at-point                              924         2.8002330000  0.0030305551
end-of-defun                                               1848        2.5033839999  0.0013546450
slime-region-for-extended-tlf-at-point                     461         1.6439540000  0.0035660607
slime-search-suppressed-forms                              922         1.5033249999  0.0016305043
font-lock-fontify-syntactically-region                     478         1.0036810000  0.0020997510
beginning-of-defun-raw                                     4233        0.4824060000  0.0001139631
beginning-of-defun                                         2382        0.4037609999  0.0001695050
slime-eval-feature-conditional                             444         0.0967099999  0.0002178153
slime-lisp-features                                        444         0.0876879999  0.0001974954
slime-forward-sexp                                         220         0.0707279999  0.0003214909
slime-forward-cruft                                        220         0.0670999999  0.0003049999
slime-forward-any-comment                                  220         0.04091       0.0001859545
font-lock-unfontify-region                                 478         0.0276759999  5.789...e-05
slime-forward-blanks                                       220         0.0211710000  9.623...e-05
font-lock-default-unfontify-region                         478         0.0208749999  4.367...e-05
slime-pre-command-hook                                     111         0.0053809999  4.847...e-05
slime-connection                                           444         0.0052940000  1.192...e-05
font-lock-extend-region-multiline                          954         0.0036339999  3.809...e-06
font-lock-extend-region-wholelines                         954         0.0034359999  3.601...e-06
slime-keywordify                                           444         0.0028710000  6.466...e-06
slime-connected-p                                          922         0.0023109999  2.506...e-06
font-lock-set-defaults                                     484         0.0016920000  3.495...e-06
jit-lock-context-fontify                                   7           0.001305      0.0001864285
slime-forward-reader-conditional                           220         0.0010509999  4.777...e-06
slime-current-connection                                   444         0.0009630000  2.168...e-06
font-lock-mode                                             8           0.000752      9.4e-05
slime-post-command-hook                                    111         0.0006969999  6.279...e-06
font-lock-default-function                                 8           0.00055       6.875e-05
font-lock-mode-internal                                    2           0.000459      0.0002295
font-lock-compile-keywords                                 2           0.000271      0.0001355
font-lock-turn-on-thing-lock                               2           0.000151      7.55e-05
jit-lock-register                                          2           9.6e-05       4.8e-05
font-lock-compile-keyword                                  32          8.500...e-05  2.656...e-06
jit-lock-mode                                              2           7.1e-05       3.55e-05
slime-lisp-mode-hook                                       1           6.7e-05       6.7e-05
slime-mode                                                 1           5.9e-05       5.9e-05
font-lock-change-mode                                      1           5.2e-05       5.2e-05
font-lock-add-keywords                                     2           4.6e-05       2.3e-05
jit-lock-refontify                                         2           3.7e-05       1.85e-05
slime-setup-command-hooks                                  1           3.2e-05       3.2e-05
font-lock-remove-keywords                                  2           2.100...e-05  1.050...e-05
slime-add-local-hook                                       2           1.8e-05       9e-06
font-lock-eval-keywords                                    2           1.5e-05       7.5e-06
font-lock-value-in-major-mode                              5           1.1e-05       2.2e-06
slime-setup-first-change-hook                              1           5e-06         5e-06
font-lock-choose-keywords                                  1           4e-06         4e-06
slime-add-easy-menu                                        1           3e-06         3e-06

Re: Low redisplay performance (23 regression)

[Tassilo Horn]

"Tobias C. Rittweiler" <tcr@freebits.de> writes:

> David Reitter <david.reitter@gmail.com> writes:
>
>> [Emacs 23.x performance regression]
>
> On a related note, I notice a big slowdown for `end-of-defun'.

And on yet another related note, today I've found out that after
changing the font scale for the current buffer using `C-x C-+' or `C-x
C--' line-by-line scrolling slows down considerably.

The performance regression can be seen very good when using the smooth
scrolling package from [1], but it's also perceptible with the emacs
defaults.

The performance hit seems to be harder on long and font-locked lines (as
others already noticed).  If I scroll my .emacs (~2000 loc) and come
across the custom-set-faces which have some lines with about 200
columns, with the smooth-scrolling package, the screen hangs for a
second and then I'm scrolled for some pages at once.

After setting the text scale back to default using `C-x C-0', scolling
works smooth again.

Oh, yet another observation: While writing this mail I enlarged the text
scale with `C-x C-+' and if I press and hold the up or down key, point
hangs for very short periods of time at some positions and then jumps
over some lines without visible redisplay, even though no scrolling at
all is done.  Resetting the font scale with `C-x C-0' and doing the
same, I can see that point crosses each and every line without jumps.

Bye,
Tassilo
__________
[1] http://www.adamspiers.org/elisp/smooth-scrolling.el

Re: Low redisplay performance (23 regression)

[David Reitter]

On Apr 29, 2009, at 1:40 PM, Tassilo Horn wrote:
>
> And on yet another related note, today I've found out that after
> changing the font scale for the current buffer using `C-x C-+' or `C-x
> C--' line-by-line scrolling slows down considerably.

As said earlier, I found that using face-remapping is highly  
correlated with this slow-down.

> Oh, yet another observation: While writing this mail I enlarged the  
> text
> scale with `C-x C-+' and if I press and hold the up or down key, point
> hangs for very short periods of time at some positions and then jumps
> over some lines without visible redisplay, even though no scrolling at
> all is done.

I see the same thing.  Did you (setq redisplay-dont-pause t) ?
Either way, it suggests that drawing takes much longer with a change  
of faces. (E.g., M-x list-faces-display ?)

Re: Low redisplay performance (23 regression)

[Tobias C. Rittweiler]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

>>   GNU Emacs 22.1.1     -->  (4.323907 2 0.07007399999999997)
>>   GNU Emacs 23.0.60.1  -->  (7.5862680000000005 1 0.048462000000000005)
>>   GNU Emacs 23.0.92.1  -->  (7.610763 2 0.06742599999999999)
>>   (built on 2009-04-29)
>
> So it's about twice as slow for this test, which is the expected in this
> case: since your benchmark always calls it with point between 2 defuns,
> it ends up doing: BOD-raw to find the previous defun, EOD-function to
> find its end, which tells Emacs that the starting point was after the
> previous defun, so it calls BOD-raw again to find the next defun and
> finally EOD-function to get to its end.

Why didn't 22.x do this? Probably to fix some bug, right?

  -T.

Re: Low redisplay performance (23 regression)

[Tassilo Horn]

David Reitter <david.reitter@gmail.com> writes:

Hi David,

>> And on yet another related note, today I've found out that after
>> changing the font scale for the current buffer using `C-x C-+' or
>> `C-x C--' line-by-line scrolling slows down considerably.
>
> As said earlier, I found that using face-remapping is highly
> correlated with this slow-down.

Ah, sorry, I must have missed that.

>> Oh, yet another observation: While writing this mail I enlarged the
>> text scale with `C-x C-+' and if I press and hold the up or down key,
>> point hangs for very short periods of time at some positions and then
>> jumps over some lines without visible redisplay, even though no
>> scrolling at all is done.
>
> I see the same thing.  Did you (setq redisplay-dont-pause t) ?

No, but setting it doesn't make a big difference here.

> Either way, it suggests that drawing takes much longer with a change
> of faces. (E.g., M-x list-faces-display ?)

Ouch!  Without remapping it scrolls with some minor hangs (tenth of a
second), but with face-remapping it starts fine, but then slows down
very quickly.  From the middle of the buffer to the last line (with
pressing and holding down, ~200 lines) it's basically a 5-10 seconds
hang followed by a jump to the last line -- nothing in between.
redisplay-dont-pause doesn't make a (noticeable) difference for me.

Bye,
Tassilo

Re: Low redisplay performance (23 regression)

[Dan Nicolaescu]

David Reitter <david.reitter@gmail.com> writes:

  > I've been noticing a substantial slowdown in redisplay performance.
  > Scrolling down emacs.c in fundamental-mode takes about 2 seconds in
  > Emacs 22 (Carbon port), and 3 seconds in Emacs 23 (NS port).
  > 
  > With font-lock-mode (in c-mode) enabled, the difference is even larger:
  > 
  > About 2.5 seconds in Emacs 22, and more than 7 seconds in 23/NS.
  > 
  > The effect interacts with the display of overlays etc. in the header
  > line.  When turning that off, I get about 2.5 seconds in Emacs 22, and
  > still more than 4 seconds in 23/NS.  (All values estimated manually
  > from several tries.)
  > 
  > I'm wondering if others get the same on other platforms comparing 22
  > and 23, or if this is a problem specifically in the NS port (for
  > example, with setting drawing color or the like).

I have not measured anything, but I do not see any visible difference on
GNU/Linux.

Re: Low redisplay performance (23 regression)

[Chong Yidong]

David Reitter <david.reitter@gmail.com> writes:

> On Apr 29, 2009, at 1:40 PM, Tassilo Horn wrote:
>>
>> And on yet another related note, today I've found out that after
>> changing the font scale for the current buffer using `C-x C-+' or `C-x
>> C--' line-by-line scrolling slows down considerably.
>
> As said earlier, I found that using face-remapping is highly
> correlated with this slow-down.

I think the problem is that lookup_basic_face computes the remapped
face_id in an expensive way.  It needs to do some caching.

Re: Low redisplay performance (23 regression)

[Tassilo Horn]

David Reitter <david.reitter@gmail.com> writes:

Hi David,

>>> As said earlier, I found that using face-remapping is highly
>>> correlated with this slow-down.
>>
>> Ah, sorry, I must have missed that.
>
> Oh no problem at all.  In fact I'm very grateful that you're
> reproducing the problem, and presumably you're reproducing it not on
> NS but elsewhere.

Yes, this is on Gentoo GNU/Linux with xft font backend (DeJaVu Sans Mono
as default face).

GNU Emacs 23.0.92.1 (x86_64-pc-linux-gnu, GTK+ Version 2.14.7) of
2009-04-28 on thinkpad

Bye,
Tassilo

Re: Low redisplay performance (23 regression)

[Stefan Monnier]

>> > As I use `end-of-defun' in my customized
>> > `font-lock-extend-region-functions' this does have an impact on the
>> > overall performance of fontification for me on large files.
>> I don't think the size of the file (aka buffer) should make
>> a difference.

> Yes, I meant to write on large defuns. I test this on a file which
> contains defuns spanning up to 500-600 lines.

Yes, that makes sense.

> I'm not sure how much you can do with this information. But I can concur
> with the OP that there does seem to be a performance regression.

Indeed font-lock-fontify-keywords-region (which is the part which I'd
expect to take the bulk of the time and would be a source of performance
problems no matter how you implement your
font-lock-extend-region-functions if you force refontification of the
whole defun every time), so as I was saying
font-lock-fontify-keywords-region got about twice as slow.  And I can't
explain it.  As far as I know, this part of font-lock has not been
changed in any significant way.  What happens if you use Emacs-22's
font-lock.el in Emacs-23?

> > So it's about twice as slow for this test, which is the expected in this
> > case: since your benchmark always calls it with point between 2 defuns,
> > it ends up doing: BOD-raw to find the previous defun, EOD-function to
> > find its end, which tells Emacs that the starting point was after the
> > previous defun, so it calls BOD-raw again to find the next defun and
> > finally EOD-function to get to its end.
> Why didn't 22.x do this? Probably to fix some bug, right?

No, you're right.  Emacs-22's code is very different, but it should end
up doing pretty much the same thing (two calls to BOD-raw plus two calls
to forward-list) and I see no reason why it should be any faster.


        Stefan

Re: Low redisplay performance (23 regression)

[Miles Bader]

David Reitter <david.reitter@gmail.com> writes:
> As said earlier, I found that using face-remapping is highly correlated
> with this slow-down.

If so, while obviously it's something to work on, it isn't a regression,
as Emacs 22 did not have this functionality...

-Miles

-- 
Road, n. A strip of land along which one may pass from where it is too
tiresome to be to where it is futile to go.

Re: Low redisplay performance (23 regression)

[YAMAMOTO Mitsuharu]

>>>>> On Wed, 29 Apr 2009 14:45:41 -0400, Chong Yidong <cyd@stupidchicken.com> said:

>>> And on yet another related note, today I've found out that after
>>> changing the font scale for the current buffer using `C-x C-+' or
>>> `C-x C--' line-by-line scrolling slows down considerably.
>> 
>> As said earlier, I found that using face-remapping is highly
>> correlated with this slow-down.

> I think the problem is that lookup_basic_face computes the remapped
> face_id in an expensive way.  It needs to do some caching.

Some profiling results show that many Lisp objects are constructed in
font_clear_prop, and that causes frequent GC triggered by Lisp
evaluations in redisplay such as mode/header-line calculation.  That
would also explain why the OP doesn't observe the slowness on Emacs 22
with backported face remapping.

				     YAMAMOTO Mitsuharu
				mituharu@math.s.chiba-u.ac.jp

Re: Low redisplay performance (23 regression)

[Chong Yidong]

YAMAMOTO Mitsuharu <mituharu@math.s.chiba-u.ac.jp> writes:

>> I think the problem is that lookup_basic_face computes the remapped
>> face_id in an expensive way.  It needs to do some caching.
>
> Some profiling results show that many Lisp objects are constructed in
> font_clear_prop, and that causes frequent GC triggered by Lisp
> evaluations in redisplay such as mode/header-line calculation.  That
> would also explain why the OP doesn't observe the slowness on Emacs 22
> with backported face remapping.

That's surprising.  I have experimented with making font_clear_prop
overwrite font specs instead of allocating new ones, when possible.
However, this does not seem to improve performance (I do not intend to
change this for 23.1).  I think the fundamental problem does not lie in
font_clear_prop, but in the fact that the face remapping code's
lookup_basic_face function calls lookup_named_face -> merge_face_vectors
far too often.

Re: Low redisplay performance (23 regression)

[Chong Yidong]

Tassilo Horn <tassilo@member.fsf.org> writes:

> And on yet another related note, today I've found out that after
> changing the font scale for the current buffer using `C-x C-+' or `C-x
> C--' line-by-line scrolling slows down considerably.

On further investigation, I found that the problem can be solved with a
relatively safe change to handle_face_prop, so that it tells
face_at_buffer_position what the base face id is rather than having
face_at_buffer_position recalculate it each time the redisplay loop
wants to display the next face (!).  I've checked in the fix.

Re: Low redisplay performance (23 regression)

[YAMAMOTO Mitsuharu]

>>>>> On Wed, 29 Apr 2009 23:49:43 -0400, Chong Yidong <cyd@stupidchicken.com> said:

>> Some profiling results show that many Lisp objects are constructed
>> in font_clear_prop, and that causes frequent GC triggered by Lisp
>> evaluations in redisplay such as mode/header-line calculation.
>> That would also explain why the OP doesn't observe the slowness on
>> Emacs 22 with backported face remapping.

> That's surprising.  I have experimented with making font_clear_prop
> overwrite font specs instead of allocating new ones, when possible.
> However, this does not seem to improve performance (I do not intend
> to change this for 23.1).  I think the fundamental problem does not
> lie in font_clear_prop, but in the fact that the face remapping
> code's lookup_basic_face function calls lookup_named_face ->
> merge_face_vectors far too often.

I confirmed that your latest change lowered the frequency of GC,
though I'm not sure which allocation is reduced most.

				     YAMAMOTO Mitsuharu
				mituharu@math.s.chiba-u.ac.jp

Re: Low redisplay performance (23 regression)

[Tobias C. Rittweiler]

Stefan Monnier <monnier@IRO.UMontreal.CA> writes:

> > I'm not sure how much you can do with this information. But I can concur
> > with the OP that there does seem to be a performance regression.
>
> Indeed font-lock-fontify-keywords-region (which is the part which I'd
> expect to take the bulk of the time and would be a source of performance
> problems no matter how you implement your
> font-lock-extend-region-functions if you force refontification of the
> whole defun every time), so as I was saying
> font-lock-fontify-keywords-region got about twice as slow.  And I can't
> explain it.  As far as I know, this part of font-lock has not been
> changed in any significant way.  What happens if you use Emacs-22's
> font-lock.el in Emacs-23?

Ok, see the profiling data below. I think I did everything the very same
as yesterday.

The first output shows the case where I linked the font-core.elc and
font-lock.elc to the .elc files of 22.1. Surprisingly that worked. :-)

You'll see that the first output shows a few less calls to END-OF-DEFUN,
and BEGINNING-OF-DEFUN(-RAW) than yesterday's data. And is a bit faster
on the whole.


The second output shows the case where I compiled the font-*.el sources
of 22.1 with a 23.x (by visiting the file, then issuing M-x
byte-compile-file.)

The second case seems to slow down everything a little bit. Although I
wouldn't vouch for the results as they're only based on 1 sample. But
has there been work on the byte-compiler?

  -T.

PS.

GNU Emacs 23.0.92.1 with font-core.elc, font-lock.elc symlinked to 22.1.

jit-lock-function                                          478         7.9711269999  0.0166759979
jit-lock-fontify-now                                       478         7.9669629999  0.0166672866
font-lock-fontify-region                                   478         7.9076759999  0.0165432552
font-lock-default-fontify-region                           478         7.8998459999  0.0165268744
font-lock-fontify-keywords-region                          478         3.9014010000  0.0081619267
slime-extend-region-for-font-lock                          953         3.2538709999  0.0034143452
slime-region-for-tlf-at-point                              922         2.3568059999  0.0025561887
end-of-defun                                               1844        2.1011199999  0.0011394360
slime-region-for-extended-tlf-at-point                     461         1.4019959999  0.0030412060
slime-search-suppressed-forms                              922         1.2786319999  0.0013868026
font-lock-fontify-syntactically-region                     478         0.6769720000  0.0014162594
beginning-of-defun-raw                                     4226        0.4991790000  0.0001181209
beginning-of-defun                                         2380        0.3932019999  0.0001652109
slime-forward-sexp                                         220         0.0930310000  0.0004228681
slime-forward-cruft                                        220         0.0895650000  0.0004071136
slime-post-command-hook                                    111         0.0680430000  0.0006130000
slime-eval-feature-conditional                             444         0.0463489999  0.0001043896
slime-forward-reader-conditional                           220         0.0386519999  0.0001756909
slime-lisp-features                                        444         0.0383999999  8.648...e-05
slime-forward-any-comment                                  220         0.0322529999  0.0001466045
font-lock-unfontify-region                                 478         0.0264229999  5.527...e-05
font-lock-default-unfontify-region                         478         0.0187470000  3.921...e-05
slime-forward-blanks                                       220         0.014927      6.785e-05
slime-connection                                           444         0.0045750000  1.030...e-05
slime-pre-command-hook                                     111         0.0045430000  4.092...e-05
font-lock-extend-region-multiline                          953         0.0034319999  3.601...e-06
font-lock-extend-region-wholelines                         953         0.0032449999  3.405...e-06
slime-connected-p                                          922         0.0029949999  3.248...e-06
slime-keywordify                                           444         0.0027099999  6.103...e-06
font-lock-set-defaults                                     484         0.0015600000  3.223...e-06
jit-lock-context-fontify                                   9           0.0014320000  0.0001591111
slime-current-connection                                   444         0.0008870000  1.997...e-06
font-lock-mode                                             14          0.000837      5.978...e-05
font-lock-default-function                                 14          0.000567      4.05e-05
font-lock-mode-internal                                    2           0.00046       0.00023
font-lock-compile-keywords                                 2           0.000273      0.0001365
font-lock-turn-on-thing-lock                               2           0.0001599999  7.999...e-05
jit-lock-register                                          2           0.0001040000  5.200...e-05
font-lock-compile-keyword                                  32          9.200...e-05  2.875...e-06
slime-lisp-mode-hook                                       1           8.9e-05       8.9e-05
slime-mode                                                 1           7.9e-05       7.9e-05
jit-lock-mode                                              2           7.6e-05       3.8e-05
slime-setup-command-hooks                                  1           4.6e-05       4.6e-05
font-lock-add-keywords                                     2           4.6e-05       2.3e-05
jit-lock-refontify                                         2           4.200...e-05  2.100...e-05
slime-add-local-hook                                       2           3.4e-05       1.7e-05
font-lock-change-mode                                      1           2.6e-05       2.6e-05
font-lock-remove-keywords                                  2           2.2e-05       1.1e-05
font-lock-value-in-major-mode                              5           1.2e-05       2.4e-06
font-lock-eval-keywords                                    2           9e-06         4.5e-06
slime-setup-first-change-hook                              1           5e-06         5e-06
slime-add-easy-menu                                        1           4e-06         4e-06
font-lock-choose-keywords                                  1           4e-06         4e-06

------------------------------------------------------------------------------

GNU Emacs 23.0.92.1 with font-core.elc, font-lock.elc byte-compiled from
22.1 sources.

jit-lock-function                                          478         8.6693530000  0.0181367217
jit-lock-fontify-now                                       478         8.6651570000  0.0181279435
font-lock-fontify-region                                   478         8.6414769999  0.0180784037
font-lock-default-fontify-region                           478         8.6329149999  0.0180604916
font-lock-fontify-keywords-region                          478         4.1605249999  0.0087040271
slime-extend-region-for-font-lock                          953         3.4857529999  0.0036576631
slime-region-for-tlf-at-point                              922         2.5261709999  0.0027398817
end-of-defun                                               1844        2.2046559999  0.0011955835
slime-region-for-extended-tlf-at-point                     461         1.411911      0.0030627136
slime-search-suppressed-forms                              922         1.3772869999  0.0014938036
font-lock-fontify-syntactically-region                     478         0.9161559999  0.0019166443
beginning-of-defun-raw                                     4226        0.4427990000  0.0001047796
beginning-of-defun                                         2380        0.4161659999  0.0001748596
slime-forward-sexp                                         220         0.1129909999  0.0005135954
slime-forward-cruft                                        220         0.1092269999  0.0004964863
slime-eval-feature-conditional                             444         0.0950729999  0.0002141283
slime-forward-any-comment                                  220         0.086004      0.0003909272
slime-lisp-features                                        444         0.0853749999  0.0001922860
font-lock-unfontify-region                                 478         0.0296069999  6.193...e-05
font-lock-default-unfontify-region                         478         0.0228370000  4.777...e-05
slime-forward-blanks                                       220         0.0164640000  7.483...e-05
slime-connection                                           444         0.0050060000  1.127...e-05
slime-pre-command-hook                                     106         0.004678      4.413...e-05
font-lock-extend-region-wholelines                         953         0.0036529999  3.833...e-06
font-lock-extend-region-multiline                          953         0.0036179999  3.796...e-06
jit-lock-context-fontify                                   19          0.002982      0.0001569473
slime-keywordify                                           444         0.0028969999  6.524...e-06
slime-connected-p                                          922         0.0022989999  2.493...e-06
font-lock-set-defaults                                     484         0.0016010000  3.307...e-06
slime-forward-reader-conditional                           220         0.0010569999  4.804...e-06
font-lock-mode                                             17          0.0010459999  6.152...e-05
slime-current-connection                                   444         0.0009930000  2.236...e-06
font-lock-default-function                                 17          0.000617      3.629...e-05
slime-post-command-hook                                    106         0.0006169999  5.820...e-06
font-lock-mode-internal                                    2           0.0004450000  0.0002225000
font-lock-compile-keywords                                 2           0.0001880000  9.400...e-05
font-lock-turn-on-thing-lock                               2           0.000158      7.9e-05
font-lock-change-mode                                      2           0.00011       5.5e-05
jit-lock-register                                          2           0.000102      5.1e-05
slime-lisp-mode-hook                                       1           9e-05         9e-05
slime-mode                                                 1           8e-05         8e-05
jit-lock-mode                                              2           7.500...e-05  3.750...e-05
font-lock-compile-keyword                                  32          6.400...e-05  2.000...e-06
font-lock-add-keywords                                     2           4.8e-05       2.4e-05
slime-setup-command-hooks                                  1           4.7e-05       4.7e-05
jit-lock-refontify                                         2           4.1e-05       2.05e-05
slime-add-local-hook                                       2           3.4e-05       1.7e-05
font-lock-remove-keywords                                  2           2.2e-05       1.1e-05
font-lock-value-in-major-mode                              5           1.2e-05       2.4e-06
font-lock-eval-keywords                                    2           9e-06         4.5e-06
slime-setup-first-change-hook                              1           5e-06         5e-06
slime-add-easy-menu                                        1           4e-06         4e-06
font-lock-choose-keywords                                  1           4e-06         4e-06

Re: Low redisplay performance (23 regression)

[Tobias C. Rittweiler]

Chong Yidong <cyd@stupidchicken.com> writes:

> Tassilo Horn <tassilo@member.fsf.org> writes:
>
>> And on yet another related note, today I've found out that after
>> changing the font scale for the current buffer using `C-x C-+' or `C-x
>> C--' line-by-line scrolling slows down considerably.
>
> On further investigation, I found that the problem can be solved with a
> relatively safe change to handle_face_prop, so that it tells
> face_at_buffer_position what the base face id is rather than having
> face_at_buffer_position recalculate it each time the redisplay loop
> wants to display the next face (!).  I've checked in the fix.

This does also effect my case positively. See PS for profiling
data. (The profiling data I sent a short moment ago in a reply to SM was
made with the same Emacs built as from yesterday.)

Your change chops off 1 second of elapsed time. Notice that I do _not_
use face-remapping. (At least I think so, `face-remapping-alist' is
nil.)

It's still slower than 22.x, though.

  -T.


PS.

GNU Emacs 23.0.92.2 (i686-pc-linux-gnu, GTK+ Version 2.12.9) of 2009-04-30

jit-lock-function                                          478         8.0091170000  0.0167554748
jit-lock-fontify-now                                       478         8.004965      0.0167467887
font-lock-fontify-region                                   478         7.9449999999  0.0166213389
font-lock-default-fontify-region                           478         7.9367379999  0.0166040543
font-lock-fontify-keywords-region                          478         4.0301240000  0.0084312217
slime-extend-region-for-font-lock                          953         3.2400959999  0.0033998908
slime-region-for-tlf-at-point                              922         2.3287470000  0.0025257559
end-of-defun                                               1844        2.0637190000  0.0011191534
slime-search-suppressed-forms                              922         1.5182759999  0.0016467201
slime-region-for-extended-tlf-at-point                     461         1.3538770000  0.0029368264
font-lock-fontify-syntactically-region                     478         0.60468       0.0012650209
beginning-of-defun-raw                                     4226        0.4219760000  9.985...e-05
beginning-of-defun                                         2380        0.3595919999  0.0001510890
slime-forward-sexp                                         220         0.1066330000  0.0004846954
slime-forward-cruft                                        220         0.1030679999  0.0004684909
slime-eval-feature-conditional                             444         0.0904689999  0.0002037590
slime-lisp-features                                        444         0.0818809999  0.0001844166
slime-forward-any-comment                                  220         0.0401569999  0.0001825318
slime-forward-reader-conditional                           220         0.0384359999  0.0001747090
font-lock-unfontify-region                                 478         0.0243780000  5.100...e-05
slime-forward-blanks                                       220         0.0204380000  9.290...e-05
font-lock-default-unfontify-region                         478         0.0180999999  3.786...e-05
slime-connection                                           444         0.0064210000  1.446...e-05
slime-pre-command-hook                                     112         0.0047230000  4.216...e-05
font-lock-extend-region-multiline                          953         0.0034039999  3.571...e-06
font-lock-extend-region-wholelines                         953         0.0031459999  3.301...e-06
slime-keywordify                                           444         0.0029510000  6.646...e-06
jit-lock-context-fontify                                   15          0.00256       0.0001706666
slime-connected-p                                          922         0.0023539999  2.553...e-06
font-lock-set-defaults                                     484         0.0015360000  3.173...e-06
slime-current-connection                                   444         0.0009280000  2.090...e-06
font-lock-mode                                             14          0.0008950000  6.392...e-05
slime-post-command-hook                                    112         0.0006179999  5.517...e-06
font-lock-default-function                                 14          0.000572      4.085...e-05
font-lock-mode-internal                                    2           0.000443      0.0002215
font-lock-compile-keywords                                 2           0.000187      9.35e-05
font-lock-turn-on-thing-lock                               2           0.0001599999  7.999...e-05
jit-lock-register                                          2           0.000102      5.1e-05
slime-lisp-mode-hook                                       1           8e-05         8e-05
jit-lock-mode                                              2           7.400...e-05  3.700...e-05
slime-mode                                                 1           7.1e-05       7.1e-05
font-lock-compile-keyword                                  32          6.6e-05       2.0625e-06
font-lock-add-keywords                                     2           4.499...e-05  2.249...e-05
slime-setup-command-hooks                                  1           4e-05         4e-05
jit-lock-refontify                                         2           3.999...e-05  1.999...e-05
slime-add-local-hook                                       2           2.600...e-05  1.300...e-05
font-lock-change-mode                                      1           2.6e-05       2.6e-05
font-lock-remove-keywords                                  2           2.2e-05       1.1e-05
font-lock-value-in-major-mode                              5           1.1e-05       2.2e-06
font-lock-eval-keywords                                    2           8e-06         4e-06
slime-setup-first-change-hook                              1           6e-06         6e-06
font-lock-choose-keywords                                  1           4e-06         4e-06
slime-add-easy-menu                                        1           3e-06         3e-06

Re: Low redisplay performance (23 regression)

[Tassilo Horn]

Chong Yidong <cyd@stupidchicken.com> writes:

Hi!

>> And on yet another related note, today I've found out that after
>> changing the font scale for the current buffer using `C-x C-+' or
>> `C-x C--' line-by-line scrolling slows down considerably.
>
> On further investigation, I found that the problem can be solved with
> a relatively safe change to handle_face_prop, so that it tells
> face_at_buffer_position what the base face id is rather than having
> face_at_buffer_position recalculate it each time the redisplay loop
> wants to display the next face (!).  I've checked in the fix.

Yes, it's much better now.  Before line-by-line scrolling in
`list-faces-display' with face-remapping was nearly impossible, now it's
not much slower than without it.

Thanks,
Tassilo

Re: Low redisplay performance (23 regression)

[David Reitter]

[-- Attachment #1: Type: text/plain, Size: 1028 bytes --]

On Apr 30, 2009, at 1:05 AM, Chong Yidong wrote:

> On further investigation, I found that the problem can be solved  
> with a
> relatively safe change to handle_face_prop, so that it tells
> face_at_buffer_position what the base face id is rather than having
> face_at_buffer_position recalculate it each time the redisplay loop
> wants to display the next face (!).  I've checked in the fix.

Thanks.  Kudos to you and Yamamoto Mitsuharu for finding these problems.
In the case that I documented, I see a big speedup, so that's good.

I still see other performance problems.
This one is easier to reproduce, I hope:

Emacs -Q
open file (e.g., src/emacs.c)
(setq redisplay-dont-pause t)
Scroll down page-wise using PgDown  [about 3 seconds]

C-x 5 2, move frame to the right so that they're side-by-side
Switch back to first frame
Home, then scroll down page-wise using PgDown [about 5 seconds}

It seems to me that this slow-down happens when the same buffer is  
shown in another frame, but not if another buffer is shown.


[-- Attachment #2: smime.p7s --]
[-- Type: application/pkcs7-signature, Size: 2193 bytes --]

Re: Low redisplay performance (23 regression)

[Stefan Monnier]

> The second case seems to slow down everything a little bit. Although I
> wouldn't vouch for the results as they're only based on 1 sample. But
> has there been work on the byte-compiler?

Yes, the byte-compiler has been changed slightly (some broken optimizations
have been fixed, mostly), so that can explain the little difference.
But still Emacs-23 with Emacs-22's font-lock.elc still takes 3.9s for
font-lock-fontify-keywords-region compared to 2.2s under Emacs-22.
So some of the underlying primitives have slowed down significantly.
Could you show the value of font-lock-keywords in that buffer?


        Stefan

Re: Low redisplay performance (23 regression)

[Tobias C. Rittweiler]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

> Could you show the value of font-lock-keywords in that buffer?

Sure.

  -T.

PS.


Value: 
(t
 (("(\\(\\(\\s_\\|\\w\\)*:\\(define-\\|do-\\|with-\\)\\(\\s_\\|\\w\\)*\\)" 1 font-lock-keyword-face)
  ("(\\(\\(define-\\|do-\\|with-\\)\\(\\s_\\|\\w\\)*\\)" 1 font-lock-keyword-face)
  ("(\\(check-\\(\\s_\\|\\w\\)*\\)" 1 font-lock-warning-face)
  (slime-search-suppressed-forms 0 'slime-reader-conditional-face t)
  ("(\\(def\\(\\(advice\\|alias\\|generic\\|macro\\*?\\|method\\|setf\\|subst\\*?\\|un\\*?\\|ine-\\(condition\\|\\(?:derived\\|\\(?:global\\(?:ized\\)?-\\)?minor\\|generic\\)-mode\\|method-combination\\|setf-expander\\|skeleton\\|widget\\|function\\|\\(compiler\\|modify\\|symbol\\)-macro\\)\\)\\|\\(const\\(ant\\)?\\|custom\\|varalias\\|face\\|parameter\\|var\\)\\|\\(class\\|group\\|theme\\|package\\|struct\\|type\\)\\)\\)\\>[ 	'(]*\\(setf[ 	]+\\sw+)\\|\\sw+\\)?"
   (1 font-lock-keyword-face)
   (9
    (cond
      ((match-beginning 3)
       font-lock-function-name-face)
      ((match-beginning 6)
       font-lock-variable-name-face)
      (t font-lock-type-face))
    nil t))
  ("^;;;###\\([-a-z]*autoload\\)" 1 font-lock-warning-face prepend)
  ("\\[\\(\\^\\)" 1 font-lock-negation-char-face prepend)
  ("(\\(cond\\(?:ition-case\\)?\\|eval-\\(?:a\\(?:fter-load\\|nd-compile\\|t-startup\\)\\|next-after-load\\|when\\(?:-compile\\)?\\)\\|i\\(?:f\\|nline\\)\\|l\\(?:ambda\\|et\\*?\\)\\|prog[*12nv]?\\|save-\\(?:current-buffer\\|excursion\\|match-data\\|restriction\\|selected-window\\|window-excursion\\)\\|track-mouse\\|unwind-protect\\|w\\(?:hile\\(?:-no-input\\)?\\|ith-\\(?:c\\(?:a\\(?:\\(?:se\\|tegory\\)-table\\)\\|urrent-buffer\\)\\|electric-help\\|local-quit\\|no-warnings\\|output-to-\\(?:string\\|temp-buffer\\)\\|s\\(?:elected-\\(?:frame\\|window\\)\\|yntax-table\\)\\|t\\(?:emp-\\(?:buffer\\|\\(?:fil\\|messag\\)e\\)\\|imeout\\(?:-handler\\)?\\)\\)\\)\\)\\>" . 1)
  ("(\\(b\\(?:\\(?:loc\\|rea\\)k\\)\\|c\\(?:ase\\|case\\|ompiler-let\\|typecase\\)\\|d\\(?:e\\(?:cla\\(?:im\\|re\\)\\|structuring-bind\\)\\|o\\(?:\\*\\|list\\|times\\)?\\)\\|e\\(?:\\(?:type\\)?case\\)\\|flet\\|go\\|handler-\\(?:bind\\|case\\)\\|i\\(?:gnore-errors\\|n-package\\)\\|l\\(?:abels\\|exical-let\\*?\\|o\\(?:cally\\|op\\)\\)\\|m\\(?:acrolet\\|ultiple-value-\\(?:bind\\|prog1\\)\\)\\|proclaim\\|re\\(?:start-\\(?:bind\\|case\\)\\|turn\\(?:-from\\)?\\)\\|symbol-macrolet\\|t\\(?:agbody\\|\\(?:h\\|ypecas\\)e\\)\\|unless\\|w\\(?:hen\\|ith-\\(?:accessors\\|co\\(?:mpilation-unit\\|ndition-restarts\\)\\|hash-table-iterator\\|input-from-string\\|o\\(?:pen-\\(?:file\\|stream\\)\\|utput-to-string\\)\\|package-iterator\\|s\\(?:imple-restart\\|lots\\|tandard-io-syntax\\)\\)\\)\\)\\>" . 1)
  ("(\\(catch\\|throw\\|featurep\\|provide\\|require\\)\\>[ 	']*\\(\\sw+\\)?"
   (1 font-lock-keyword-face)
   (2 font-lock-constant-face nil t))
  ("(\\(abort\\|assert\\|warn\\|check-type\\|cerror\\|error\\|signal\\)\\>" 1 font-lock-warning-face)
  ("\\\\\\\\\\[\\(\\sw+\\)\\]" 1 font-lock-constant-face prepend)
  ("`\\(\\sw\\sw+\\)'" 1 font-lock-constant-face prepend)
  ("\\<:\\sw+\\>" 0 font-lock-builtin-face)
  ("\\<\\&\\sw+\\>" . font-lock-type-face)
  ((lambda
       (bound)
     (catch 'found
       (while
           (re-search-forward "\\(\\\\\\\\\\)\\(?:\\(\\\\\\\\\\)\\|\\((\\(?:\\?[0-9]*:\\)?\\|[|)]\\)\\)" bound t)
         (unless
             (match-beginning 2)
           (let
               ((face
                 (get-text-property
                  (1-
                   (point))
                  'face)))
             (when
                 (or
                  (and
                   (listp face)
                   (memq 'font-lock-string-face face))
                  (eq 'font-lock-string-face face))
               (throw 'found t)))))))
   (1 'font-lock-regexp-grouping-backslash prepend)
   (3 'font-lock-regexp-grouping-construct prepend)))
 ("(\\(\\(\\s_\\|\\w\\)*:\\(define-\\|do-\\|with-\\)\\(\\s_\\|\\w\\)*\\)"
  (1 font-lock-keyword-face))
 ("(\\(\\(define-\\|do-\\|with-\\)\\(\\s_\\|\\w\\)*\\)"
  (1 font-lock-keyword-face))
 ("(\\(check-\\(\\s_\\|\\w\\)*\\)"
  (1 font-lock-warning-face))
 (slime-search-suppressed-forms
  (0 'slime-reader-conditional-face t))
 ("(\\(def\\(\\(advice\\|alias\\|generic\\|macro\\*?\\|method\\|setf\\|subst\\*?\\|un\\*?\\|ine-\\(condition\\|\\(?:derived\\|\\(?:global\\(?:ized\\)?-\\)?minor\\|generic\\)-mode\\|method-combination\\|setf-expander\\|skeleton\\|widget\\|function\\|\\(compiler\\|modify\\|symbol\\)-macro\\)\\)\\|\\(const\\(ant\\)?\\|custom\\|varalias\\|face\\|parameter\\|var\\)\\|\\(class\\|group\\|theme\\|package\\|struct\\|type\\)\\)\\)\\>[ 	'(]*\\(setf[ 	]+\\sw+)\\|\\sw+\\)?"
  (1 font-lock-keyword-face)
  (9
   (cond
     ((match-beginning 3)
      font-lock-function-name-face)
     ((match-beginning 6)
      font-lock-variable-name-face)
     (t font-lock-type-face))
   nil t))
 ("^;;;###\\([-a-z]*autoload\\)"
  (1 font-lock-warning-face prepend))
 ("\\[\\(\\^\\)"
  (1 font-lock-negation-char-face prepend))
 ("(\\(cond\\(?:ition-case\\)?\\|eval-\\(?:a\\(?:fter-load\\|nd-compile\\|t-startup\\)\\|next-after-load\\|when\\(?:-compile\\)?\\)\\|i\\(?:f\\|nline\\)\\|l\\(?:ambda\\|et\\*?\\)\\|prog[*12nv]?\\|save-\\(?:current-buffer\\|excursion\\|match-data\\|restriction\\|selected-window\\|window-excursion\\)\\|track-mouse\\|unwind-protect\\|w\\(?:hile\\(?:-no-input\\)?\\|ith-\\(?:c\\(?:a\\(?:\\(?:se\\|tegory\\)-table\\)\\|urrent-buffer\\)\\|electric-help\\|local-quit\\|no-warnings\\|output-to-\\(?:string\\|temp-buffer\\)\\|s\\(?:elected-\\(?:frame\\|window\\)\\|yntax-table\\)\\|t\\(?:emp-\\(?:buffer\\|\\(?:fil\\|messag\\)e\\)\\|imeout\\(?:-handler\\)?\\)\\)\\)\\)\\>"
  (1 font-lock-keyword-face))
 ("(\\(b\\(?:\\(?:loc\\|rea\\)k\\)\\|c\\(?:ase\\|case\\|ompiler-let\\|typecase\\)\\|d\\(?:e\\(?:cla\\(?:im\\|re\\)\\|structuring-bind\\)\\|o\\(?:\\*\\|list\\|times\\)?\\)\\|e\\(?:\\(?:type\\)?case\\)\\|flet\\|go\\|handler-\\(?:bind\\|case\\)\\|i\\(?:gnore-errors\\|n-package\\)\\|l\\(?:abels\\|exical-let\\*?\\|o\\(?:cally\\|op\\)\\)\\|m\\(?:acrolet\\|ultiple-value-\\(?:bind\\|prog1\\)\\)\\|proclaim\\|re\\(?:start-\\(?:bind\\|case\\)\\|turn\\(?:-from\\)?\\)\\|symbol-macrolet\\|t\\(?:agbody\\|\\(?:h\\|ypecas\\)e\\)\\|unless\\|w\\(?:hen\\|ith-\\(?:accessors\\|co\\(?:mpilation-unit\\|ndition-restarts\\)\\|hash-table-iterator\\|input-from-string\\|o\\(?:pen-\\(?:file\\|stream\\)\\|utput-to-string\\)\\|package-iterator\\|s\\(?:imple-restart\\|lots\\|tandard-io-syntax\\)\\)\\)\\)\\>"
  (1 font-lock-keyword-face))
 ("(\\(catch\\|throw\\|featurep\\|provide\\|require\\)\\>[ 	']*\\(\\sw+\\)?"
  (1 font-lock-keyword-face)
  (2 font-lock-constant-face nil t))
 ("(\\(abort\\|assert\\|warn\\|check-type\\|cerror\\|error\\|signal\\)\\>"
  (1 font-lock-warning-face))
 ("\\\\\\\\\\[\\(\\sw+\\)\\]"
  (1 font-lock-constant-face prepend))
 ("`\\(\\sw\\sw+\\)'"
  (1 font-lock-constant-face prepend))
 ("\\<:\\sw+\\>"
  (0 font-lock-builtin-face))
 ("\\<\\&\\sw+\\>"
  (0 font-lock-type-face))
 ((lambda
      (bound)
    (catch 'found
      (while
          (re-search-forward "\\(\\\\\\\\\\)\\(?:\\(\\\\\\\\\\)\\|\\((\\(?:\\?[0-9]*:\\)?\\|[|)]\\)\\)" bound t)
        (unless
            (match-beginning 2)
          (let
              ((face
                (get-text-property
                 (1-
                  (point))
                 'face)))
            (when
                (or
                 (and
                  (listp face)
                  (memq 'font-lock-string-face face))
                 (eq 'font-lock-string-face face))
              (throw 'found t)))))))
  (1 'font-lock-regexp-grouping-backslash prepend)
  (3 'font-lock-regexp-grouping-construct prepend))
 ("^\\s("
  (0
   (if
    (memq
     (get-text-property
      (match-beginning 0)
      'face)
     '(font-lock-string-face font-lock-doc-face font-lock-comment-face))
    (list 'face font-lock-warning-face 'help-echo "Looks like a toplevel defun: escape the parenthesis"))
   prepend)))

Local in buffer l1-unicode.lisp; global value is nil

Re: Low redisplay performance (23 regression)

[Willem Rein Oudshoorn]

Miles Bader <miles@gnu.org> writes:

> Willem Rein Oudshoorn <woudshoo@xs4all.nl> writes:
>> M-x list-charset-chars
>>     mule-unicode-0100-24ff
>>
>> scrolling in the resulting buffer is extremely slow.  
>> PgUp PgDn, C-n C-p will eat up 100% and it is very jerky.
>>
>> This is both on mswindows and Mac OS X.  
>
> Have you tried doing it (scrolling through the buffer) _twice_?

Yes, scenario is:

1 show unicode chars with: M-x list-charset-chars mule-unicode-0100-24ff
2 keep C-n pressed.
3 when finally at the end of the buffer jump to begin of buffer
4 keep C-n pressed.

The slowdown in step 4 is comparable to the slowdown in step 2.

But I read that there have been improvements and I will check the
newest version sometime this week and let you know.

Wim Oudshoorn.
P.S.: Sorry for the late reply, but there was a funeral in the family
      and obviously that took precedence over anything computer related.