> But could you maybe run the benchmark under gprof and see what you get? Just curious.

I did, I just don't understand gprof's output very well. I've attached
two gmon.out and perf.data files if you have anything specific in mind
to try.

>> So, is caching worth it? I don't know. It definetily is if it's possible
>> to do it internally without introducing a new object type. But I don't
>> think that's possible without making a hash map or a complicated cache
>> like the one for compiled regexps that compile_pattern uses in
>> search.c.
>
> Yeah using a single cache would probably result in a lot of misses since Emacs
> don’t fontify the whole buffer at once. We don’t necessarily need to use a hash
> map. I had a look at search.c and IIUC it uses an Emacs-wide array of 20 regex
> caches and links them into a linked list sorted by most-recently used, which
> doesn’t seem too bad? I think I can do something similar to that. Tho we might
> also want to allow users to pin some “persistent” cache, for example major mode
> font-locking and indent queries, as they are guaranteed to be reused a lot and
> are generally large (ie, slow to create). Maybe that’s unnecessary tho. And I
> wonder if there is a cheap & easy way to do caching buffer-locally…
>
> Or maybe add an argument to query-capture that allow the user to specify whether
> they want the query to be cached, or assume user wants the query to be cached if
> the query is in string form rather than in sexp form.

Eli/Stefan, please guide us!


  Yoav