NeXTStep port: slowness, etc.

NeXTStep port: slowness, etc.

[David Reitter]

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

I'm experiencing a delay of almost one second when accessing on menus,  
i.e. there is a long lag between clicking on a menu title and the menu  
actually showing up.  That shouldn't be.

Also, some mouse-hover effect seems excessively slow:

M-x lisp-interaction mode
(frame-parameters nil)
C-j
(go to the "..." ellipsis)
RET
move mouse over the buffer contents, which are then shown with a green  
background.

The green background appears very gradually, it takes about 0.5  
seconds to completely appear.

This is no the case in (Carbon) Emacs 22.

Other (re)drawing operations are very fast - scrolling etc. seems much  
improved from 22/Carbon.

NB, Emacs -> About Emacs should go to `about-emacs'. Remove "Report  
Emacs.app bug", I guess these go to the usual destination now. 

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

Re: NeXTStep port: slowness, etc.

[Adrian Robert]

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

> 
> I'm experiencing a delay of almost one second when accessing on menus,  
> i.e. there is a long lag between clicking on a menu title and the menu  
> actually showing up.  That shouldn't be.

This is due to this change:

2008-07-15  Stefan Monnier  <monnier@iro.umontreal.ca>

	* keyboard.c (parse_menu_item): Don't use cachelist, even under NS.
	If the cache doesn't work, let's fix it, rather than work around it.

This is the right thing to do, but it means some significant work
may be needed to recover normal performance.  When I looked into
this, my best guess was that further optimization needed to be
done in the ns menu code.  ns_update_menubar() from line 108 in
nsmenu.m.  I did my best to follow other terms as closely as
possible, and even optimize more than they do, but something is
wrong somewhere.  Also see comment on line 242.  There is some
profiling code that can be enabled.

It could also be that the problem has not to do with nsmenu.m,
but something with the way other code is leading to the calling
of ns_update_menubar().  Either something of the new cache
referred to in keyboard.c is hit differently by the NS port for
some reason, or ns_update_menubar() is called in some different
pattern.

I spent some time on this but could not get any further -- it
might be another pair of eyes can see what I'm missing.


BTW, the "incremental" mouse highlighting you mention has been
there for a while, another thing I could not track down.  Again,
NS handles this identically to other terms as far as I've been
able to tell, but there must be a difference somewhere..

Re: NeXTStep port: slowness, etc.

[Stefan Monnier]

> This is the right thing to do, but it means some significant work
> may be needed to recover normal performance.  When I looked into

I don't think so.  E.g. If you replace Qsuper with Qt in the call to
where_is_internal, you should get back the normal speed.


        Stefan