Re: Text properties slow down XEmacs

Ben Wing <ben(a)666.com&gt; "says": > The major time is not is not spent in creating extents but in > mapextent That is not the point: Major parts of the time are spent in creating 'text-properties'. The problem is that because the fact that this is non using _non-overlapping_ extents this involves doing a map-extents over all extents overlaying a region and that is about the slowest operations possible on extents. I am suggesting that some representation (of font-lock info or of text properties in general) involving overlapping extents might possibly be much faster since you would only need 'map over all extents with endpoints in the region' which is fast. The redisplay code can (and already does) do the collapsing of these stacks of extents efficiently. All the text-property query code would then become slower but at least for font-lock that is a non-issue. > just speeding up mapextent might suffice. Agreed. Maybe the extent fragment code should be moved up a level so the text properties code can use it. > operations on extents or text-properties tend to be localised. May be the problem is that in 'font-lock-fontify-buffer' it really isn't? > [several comments about that font-lock needs to merge extents etc] Could somebody please give an example where font-lock NEEDS to merge extents 1. in font-lock-fontify-buffer 2. While editing (i.e. re-fontifying a restricted number of lines in the buffer) and please not the \alpha\beta example. I have the feeling that if it is during 2 then it is better to have the slow map-extent there since doing it once or twice it is still fast enough to keep up with the user. During the initial font-lock this is done 36000 times! Jan