Re: Checking new mail very slow with current CVS

[Jan Vroonhof <jvlists@ntlworld.com>]

Simon Josefsson <jas@extundo.com> writes:

>> You guys are aware that XEmacs has native profiling support (see
>> 'start-profiling')?
>
> Cool!  I wasn't aware of it, it seems to give more reliable results.
> (Shouldn't `start-profiling' be a interactive function?)

Possibly... The main interactive use is supposed to be M-x
profile-key-sequence or lisp-eval calls..

>> Although that does not do tree based profiling.
>
> What is that?  Does elp do it?

I meant that the fact the current XEmacs profiling only counts time to
the function we are actually in. i.e. in

(def foo ()
    bar())

If bar takes 3 seconds that time isn't counted to foo.  XEmacs does
this because it is most easy to implement if you do sample based
profiling.

Elp on the other hand attributes the time to both foo and bar. That is
more easy to do if you do wrapping. It would be possible to add this
to XEmacs as well (for instance by walking the stack on each profiling
tick).

True tree based profiling will give you times for each path from the
root in the call tree, i.e.  with tell you we spend 3 seconds in bar
when called from foo and 0.5 seconds when called from xyz.

All three are useful. The current XEmacs way is better at spotting
lowlevel hotspots, for instance so we know which C functions to
optimize to make that app go futher. The elp way is better at spotting
higher-level problem (and luckily the loss of accuracy isn't as
important there).

Jan