At 02:49 PM 7/6/01 +0200, Joaqu�n Cuenca Abela wrote:
>I've been taking a look at our pf_Fragments, and after some UT_DEBUGMSG
>I've seen that the searches for pf_Frag's are very (*very*) local. So
>I've added a little cache (of only 1 element) to this class.
Yay! When Jeff and I originally designed the piece table, this is the exact
optimization we thought would be most promising, but we decided to wait
until we had enough real-world profile data to prove it was worth it.
For example, until you have profile data on the calling patterns of a
fully-functional word processor, it's very hard to compare the following
potential optimization strategies:
- no caches,
- a last lookup cache (Joaquin),
- a binary search (Martin),
- both of the above (like we have now), or even
- another variant which seeds the binary search using Joaquin's cache.
At the time (circa 0.1.1) we were still working to get on-screen editing
working *at all* inside paragraphs, and getting across block boundaries into
paragraph two or three was still a future TODO.
Boy we've come a long way since then, huh? ;-)
Paul
PS: If anyone wants to have even more fun with their profiler, it might be
interesting to experiment with various caching strategies and see how they
compare.
