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?
>
> Naturally, I count fontification of large buffers and Summary buffer
> creation as "practical purposes." Profiles of Summary creation have
> been published in the past so there is no need to rehash that. Let's
> look at a fontification profile instead.
>
> Where would you expect most time is being spent during fontification?
> My bet would be regexp-matching. Well, wrong!
It depends I guess. This is from fontifing events.c
Function Name Ticks %/Total Call Count
================================= ===== ======= ==========
re-search-forward 612 47.332 6960
put-nonduplicable-text-property 186 14.385 12140
map-extents 94 7.270 7962
font-lock-fontify-keywords-region 87 6.729 2
syntactically-sectionize 74 5.723 2
(in garbage collection) 65 5.027
looking-at 52 4.022 8386
font-lock-match-c++-style-declaration-item-and-skip-to-next 28 2.166 4626
store-match-data 14 1.083 4669
extent-property 14 1.083 6616
match-data 13 1.005 4669
byte-code 12 0.928 2095
on a 21.0 Mule. Here is from a local 70K TeX file on 20.4-latin1
Function Name Ticks %/Total
======================================= ===== =======
put-nonduplicable-text-property 736 43.914
map-extents 311 18.556
re-search-forward 250 14.916
font-lock-fontify-keywords-region 236 14.081
extent-property 24 1.432
(in garbage collection) 22 1.313
syntactically-sectionize 20 1.193
> So, by *far* the most time (35%) is getting spent in the text-props
> code, in an XEmacs compiled *without* error checking.
I was really surprised at the call counts for
put-nonduplicable-text-property.
> I suspect this
> code is much faster in FSF Emacs because they support text properties
> directly through the use of balanced trees, while we emulate them
> using non-overlapping extents, which are stored as a simple ordered
> list in the buffer.
AFAICS can see put-nonduplicable-text-property seems to hit a worst
case in in map_extents_bytind. It should be really trivial/fast to find the
extents overlapping a certain region, especially when there only
non-overlapping extents..
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.
> 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.
