Hrvoje Niksic <hniksic(a)srce.hr&gt; writes: Are you using a mule or a nonmule XEmacs? 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 I was really surprised at the call counts for put-nonduplicable-text-property. 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. Why is font-lock using text-properties anyway? Isn't what it does much more naturally mapped on extents.