I'm more and more convinced that our extent-based text properties interface is what is slowing XEmacs down for most practical purposes. 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! Here is the actual profile: Function Name Ticks %/Total Call Count ================================= ===== ======= ========== put-nonduplicable-text-property 251 34.958 31856 re-search-forward 131 18.245 16120 font-lock-fontify-keywords-region 113 15.738 1 (in garbage collection) 100 13.928 map-extents 94 13.092 13931 text-property-any 14 1.950 3787 get-text-property 9 1.253 1909 next-single-property-change 6 0.836 1909 ------------------------------------------------------------------ Total 718 100.00 One tick = 1 ms So, by *far* the most time (35%) is getting spent in the text-props code, in an XEmacs compiled *without* error checking. 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. It's kind of sad that all of our enhancements to font-lock are getting nullified by these problems. :-( -- Hrvoje Niksic <hniksic(a)srce.hr&gt; | Student at FER Zagreb, Croatia --------------------------------+-------------------------------- If anything goes wrong, blame the random-number generator!