Jan Vroonhof <vroonhof(a)math.ethz.ch> writes:
Hrvoje Niksic <hniksic(a)srce.hr> writes:
> I'm more and more convinced that our extent-based text properties
> interface is what is slowing XEmacs down for most practical purposes.
Are you using a mule or a nonmule XEmacs?
A noon-Mule XEmacs.
It depends I guess. This is from fontifing events.c
It does depend. This is what I get for events.c:
re-search-forward 96 36.364 2786
put-nonduplicable-text-property 56 21.212 5608
map-extents 24 9.091 3470
(in garbage collection) 24 9.091
Still, 21% time in textprops code is a lot. It would be nice if we
could do the same kind of profiling in FSF Emacs and see how much time
they lose in textprops code. I'd be willing to bet that that time is
negligible.
It would be interesting to see where the time is spent in
map_extents_bytind. Note this in extents.c
If the lists were stored as balanced binary trees, then operation (1)
would take logarithmic time, which is usually quite fast. However,
currently they're stored as simple doubly-linked lists, and instead
we do some caching to try to speed things up.
It seems as though the caching is not working in all cases. Maybe the
linked list should be replaced by a (splay) tree or a skip list.
David Moore hinted at something similar some time in 1997. He said
that the extents code is probably as fast as you can get using linear
data structures.
> It's kind of sad that all of our enhancements to font-lock
are
> getting nullified by these problems. :-(
Why is font-lock using text-properties anyway? Isn't what it does
much more naturally mapped on extents.
Not really (although it may look that way at the start). The
font-lock code wants to apply certain properties to parts of the
buffer, merging or breaking the extents as needed. This is exactly
what the text-properties are for.
--
Hrvoje Niksic <hniksic(a)srce.hr> | Student at FER Zagreb, Croatia
--------------------------------+--------------------------------
We are all just prisoners here of our own MAKEDEV.