Uwe Brauer wrote:
>>>>>"David" == David Kastrup
<dak(a)gnu.org> writes:
>>>>>
>>>>>
>>
>>>>>>>> "David" == David Kastrup <dak(a)gnu.org>
writes:
>>>
David> M-x elp-results RET
>>>
>>> Thanks, this function also exists in xemacs (and I did not know
>>> about it), in any case the information is very aehm spare:
>>
>> You should probably also instrument the `nnml', `imap', `mm' and
`mml'
>> packages (and maybe some more depending on which operation you're
>> benchmarking -- I don't recall).
David> And it helps to run the test first before instrumenting it: that way
David> not only the autoloads get instrumented.
Ok, thanks, I think now more or less I know how to proceed. As I said
before the situation is sort of strange: for a certain amount of msg,
say n, both emacsen are almost equal, gnu emacs a little faster, once
the number of msg > n, then xemacs got stacked.
it would be very nice to know where the problem is. sometimes typing
Control-Shift-G in XEmacs will break out and give you a backtrace. (it
should always do that but maybe sometimes doesn't ...) If not, try
setting Options->Troubleshooting->Debug on Quit, then manually do `kill
-INT ###', where ### is the process id of XEmacs. (maybe it's `kill
-SIGINT ###', i forget)
I should add, that the information of the elp packages is detailed
the
profile-command of xemacs gives far more information. I don't know how
important profiling is for emacs, but may that pkg could be ported?
the problem is that the XEmacs profile stuff depends on C support, which
is how it's able to do all the nifty things it does.
ben