Re: Speed difference in Gnus
Hrvoje Niksic wrote:
The speed difference between XEmacs and GNU Emacs is amazing, in that
GNU Emacs is significantly faster, at least for "heavy" usage such as
Gnus. Entering a large summary buffer takes time proportional to the
*square* of the number of messages in the folder. (This is not a wild
guess, a friend has actually measured.) Time to enter a folder of
more than 3000 articles quickly degrades to minutes.
For the longest time I believed this to be a result of XEmacs's
implementation of text properties on top of extents. I planned to
convert Gnus to use extents natively, in the hope that it would speed
up summary buffer generation. But according to profiling, most of the
time is spent in `insert', at least once you discount excessive GC by
increasing gc-cons-theshold. I'm not sure what XEmacs is doing wrong
here. I suspect Mule is to blame, but I can't prove it.
Using FSF Emacs gave me an order-of-magnitude speedup when entering
large newsgroups and large mailing list folders. It's uncanny.
first of all, are you sure you're running without error-checking? with
error-checking, there's some extent sledgehammer checks that could
easily give you the quadratic behavior.
as for mule, i don't think that's the case; or at least, you'd see a lot
of time going to `in-char-byte-conversion' in the profiling table.
it's also still possible it's the text property implementation. i know
that the extent code works very badly in the presence of a single extent
that covers the entire buffer, which is a common occurrence given the
way that text properties currently work. i have a new implementation of
text properties sitting in one of my workspaces, which redoes them the
way they are implemented in fsf -- i.e. as completely non-overlapping
intervals. it's all written, but as usual it needs some
testing/debugging work ... sigh ...
but maybe you're right about the textprops not being the culprit; the
only way they could be inside of insert is through `adjust_extents()' or
friends ...
you might try adding some profiling sections to cover certain parts of
the `insert' call. take a look at e.g. charbpos_to_bytebpos_func() and
you'll see how to add a profiling section to cover a certain part of
code; it's pretty easy at this point.
ben