menu-bar-update-hook performance problems

menu-bar-update-hook performance problems

[Dan Debertin]

-- 
One of the extensions in my .emacs is causing performance problems,
but I'm having trouble figuring out which one it is. From everything
elp.el is telling me, menu-bar-update-hook is being called *way* too
many times a second, but I can't seem to find a way to tell what's
causing it to be called. One of these bits of information would get
me most of the way there:

o Under exactly what circumstances menu-bar-update-hook is called. A
    usenet search shows that some think it gets called too frequently,
    but I can't find any information in the elisp manual about it
    apart from "This normal hook is run whenever the user clicks on
    the menu bar, before displaying a submenu". I'm definitely not
    clicking on the menu-bar several times a second; in fact I'm not
    touching it at all.

o How to instrument built-in functions for Edebug, so I can get a
    backtrace and figure out what's calling 
    (run-hooks 'menu-bar-update-hook). The documentation says that 
    you have to re-evaluate the defun with C-u C-M-x, but I obviously 
    can't do that with built-ins. Right?

TIA,

Dan
--
/^Dan Debertin$/         |
airboss@nodewarrior.org  | 
www.nodewarrior.org      | 

Re: menu-bar-update-hook performance problems

[Kai Großjohann]

Dan Debertin <airboss@nodewarrior.org> writes:

> o How to instrument built-in functions for Edebug, so I can get a
>     backtrace and figure out what's calling 
>     (run-hooks 'menu-bar-update-hook). The documentation says that 
>     you have to re-evaluate the defun with C-u C-M-x, but I obviously 
>     can't do that with built-ins. Right?

It's much easier: put your own function on the hook that invokes
(debug).  From there you can examine the backtrace and then continue.

Hm.  OTOH, whether this simple approach works for
menu-bar-update-hook, of all places, I'm not so sure.  Invoking the
debugger changes the menu bar...
-- 
A preposition is not a good thing to end a sentence with.

Re: menu-bar-update-hook performance problems

[Dan Debertin]

kai.grossjohann@uni-duisburg.de (Kai Großjohann) writes:


> Hm.  OTOH, whether this simple approach works for
> menu-bar-update-hook, of all places, I'm not so sure.  Invoking the
> debugger changes the menu bar...

So you see my dilemma :). Updating the mode-line also calls
menu-bar-update-hook, so anything that touches the mode-line is also
off-limits. 

My next trick was to add this to the head of menu-bar-update-hook:

(lambda ()
   (save-excursion       
     (set-buffer (get-buffer-create "*temp-trace*"))
       (insert (prin1-to-string (backtrace))))))

But, sadly, the backtraces I get out of it (and boy, do I ever get
backtraces) stop at 'run-hooks'. Perhaps I will advise run-hooks.


Dan
--
/^Dan Debertin$/         |
airboss@nodewarrior.org  | 
www.nodewarrior.org      | 

Re: menu-bar-update-hook performance problems

[Kai Großjohann]

Dan Debertin <airboss@nodewarrior.org> writes:

> But, sadly, the backtraces I get out of it (and boy, do I ever get
> backtraces) stop at 'run-hooks'. Perhaps I will advise run-hooks.

What do you mean "stop at"?  Doesn't it show the function that called
run-hooks in the line below run-hooks?

If there is a lot of gibberish in the backtraces, you might have to
load some *.el files (instead of *.elc files) to get real Lisp code.
(I'm guessing you know how to do that.)
-- 
A preposition is not a good thing to end a sentence with.

Re: menu-bar-update-hook performance problems

[Dan Debertin]

Hi,

kai.grossjohann@uni-duisburg.de (Kai Großjohann) writes:

> 
> What do you mean "stop at"?  Doesn't it show the function that called
> run-hooks in the line below run-hooks?

By "stop at" I mean that there is nothing before run-hooks in the backtrace.


Dan
--
/^Dan Debertin$/         |
airboss@nodewarrior.org  | 
www.nodewarrior.org      | 

Re: menu-bar-update-hook performance problems

[Kai Großjohann]

Dan Debertin <airboss@nodewarrior.org> writes:

> kai.grossjohann@uni-duisburg.de (Kai Großjohann) writes:
>
>> 
>> What do you mean "stop at"?  Doesn't it show the function that called
>> run-hooks in the line below run-hooks?
>
> By "stop at" I mean that there is nothing before run-hooks in the
> backtrace.

By "before", do you mean "above"?

Note that backtraces are, as the name suggests, backwards: If f1 calls
f2 which calls f3, then the backtrace will show f3 at the top and f1
at the bottom.

Maybe you could show us the backtrace -- I fear that a
misunderstanding is happening here.
-- 
A preposition is not a good thing to end a sentence with.

Re: menu-bar-update-hook performance problems

[Stefan Monnier]

>>>>> "Dan" == Dan Debertin <airboss@nodewarrior.org> writes:
> (lambda ()
>    (save-excursion       
>      (set-buffer (get-buffer-create "*temp-trace*"))
>        (insert (prin1-to-string (backtrace))))))

> But, sadly, the backtraces I get out of it (and boy, do I ever get
> backtraces) stop at 'run-hooks'. Perhaps I will advise run-hooks.

It's probably because the hook is run from the C code, so there
is no previous elisp function on the stack.  You'll need
to debug it at the C level, I'm afraid.


        Stefan

Re: menu-bar-update-hook performance problems

[Kai Großjohann]

kai.grossjohann@uni-duisburg.de (Kai Großjohann) writes:

> It's much easier: put your own function on the hook that invokes
> (debug).  From there you can examine the backtrace and then continue.
>
> Hm.  OTOH, whether this simple approach works for
> menu-bar-update-hook, of all places, I'm not so sure.  Invoking the
> debugger changes the menu bar...

Another idea: put a function on menu-bar-update-hook that let-binds
menu-bar-update-hook to nil, then invokes (debug).

Maybe it works.
-- 
A preposition is not a good thing to end a sentence with.

Re: menu-bar-update-hook performance problems

[Kevin Rodgers]

Dan Debertin wrote:
 > One of the extensions in my .emacs is causing performance problems,
 > but I'm having trouble figuring out which one it is. From everything
 > elp.el is telling me, menu-bar-update-hook is being called *way* too
 > many times a second, but I can't seem to find a way to tell what's
 > causing it to be called. One of these bits of information would get
 > me most of the way there:
 >
 > o Under exactly what circumstances menu-bar-update-hook is called. A
 >     usenet search shows that some think it gets called too frequently,
 >     but I can't find any information in the elisp manual about it
 >     apart from "This normal hook is run whenever the user clicks on
 >     the menu bar, before displaying a submenu". I'm definitely not
 >     clicking on the menu-bar several times a second; in fact I'm not
 >     touching it at all.

Does `M-x apropos-value RET menu-bar-update-hook RET' reveal anything?

-- 
<a href="mailto:&lt;kevin.rodgers&#64;ihs.com&gt;">Kevin Rodgers</a>