Re: Text properties slow down XEmacs
"Stephen J. Turnbull" <turnbull(a)sk.tsukuba.ac.jp> writes:
Hrvoje> I think the code would be more complex if font-lock
Hrvoje> attempted to do the merging/breaking by itself, but I
Hrvoje> might be wrong. It would certainly be faster that way...
Given that we implement text properties in terms of extents, I don't
see a speed gain
The speed gain is pretty obvious, once you think about it. Font-lock
does specific things in a buffer, using text properties. However,
text properties interface is not optimized for speed, but for FSF
compatibility and whatnot. Jan has demonstrated how overlapping
extents can simplify stuff that looks very complex with textprops.
It remains to be seen about the complexity increase.
Hrvoje> My point was that the "native"
balanced-tree
Hrvoje> implementation of text properties is bound to be faster
Hrvoje> than emulating them with extents. Perhaps I am wrong on
Hrvoje> that one, too. I would certainly *like* to be wrong on
Hrvoje> that one.
The way the text properties interface is defined, I really don't see
them as anything but a restriction of the extent interface.
Yes, and this restriction allows for optimization, doesn't it? For
example, their text properties can't overlap.
In the end, for redisplay we _must_ update an extent when we change
a text property, for at least a significant fraction of the uses of
text properties. We may as well implement the character ranges
implicit in a balanced-tree implementation of text properties as
extents, and get that update "for free". No?
I don't know.
--
Hrvoje Niksic <hniksic(a)srce.hr> | Student at FER Zagreb, Croatia
--------------------------------+--------------------------------
Suburbia is where the developer bulldozes out the trees, then names
the streets after them. -- Bill Vaughn