bug#63225: Compiling regexp patterns (and REGEXP_CACHE_SIZE in search.c)

["Mattias Engdegård" <mattias.engdegard@gmail.com>]

3 maj 2023 kl. 18.02 skrev Ihor Radchenko <yantar92@posteo.net>:

> What is the aim of instrumenting regexp engine in this scenario?
> I already know that additional regexps will be tested by individual
> `org-element-X-parser' functions.

I got the impression that the 'spine' of the parser, the sequence of `looking-at` calls in `org-element--current-element`, would frequently be run through in its entirety which means that consolidating these would reduce the number of working regexps by about 20 (if I'm counting correctly).

Now if as you suggest the parsing is dominated by sequences of regexps in the branches, it prompts the questions: which branches, what regexps, why are there so many of them, and is there anything that can be done to reduce their number?

> I am also not sure how to instrument the regexp engine and what I can
> see there.

Sorry, it is just what I who know nothing about the structure of Org would do to get a better view. You may find it easier to work at the Lisp level.