GNU bug report logs - #63225
Compiling regexp patterns (and REGEXP_CACHE_SIZE in search.c)

Previous Next

Full log

View this message in rfc822 format

From: Ihor Radchenko <yantar92 <at> posteo.net>
To: Mattias Engdegård <mattias.engdegard <at> gmail.com>
Cc: 63225 <at> debbugs.gnu.org
Subject: bug#63225: Compiling regexp patterns (and REGEXP_CACHE_SIZE in search.c)
Date: Mon, 08 May 2023 19:44:47 +0000

Mattias Engdegård <mattias.engdegard <at> gmail.com> writes:

> 8 maj 2023 kl. 15.56 skrev Ihor Radchenko <yantar92 <at> posteo.net>:
>
>> I am not sure what I can make out of hits/misses, but I am at least able
>> to look into frequency data, via sort re.log  | uniq -c > re-freq.log
>
> I'm mostly curious about the regexp cache behaviour. What cache size
> did you use in this run?

50

> Hardly 20, given the low miss rate? It would be interesting to see what sequence of regexps most commonly cause thrashing.

Here is the log:
https://0x0.st/HZgH.log

>> It would be even nicer if apart from frequency, there was information
>> about time taken to search for each regexp.
>
> That's a bit messier but could be done if really needed.

From this discussion, I am, so far, having an impression that Elisp
regexps can various non-obvious pitfalls that may need to be considered.
However, Org uses so many regexps that optimizing them all is not a
viable option, especially when the optimization may involve changing the
syntax.  Having the data on the major bottlenecks would at least allow
us to focus on the regexps that really slow things down in practice.

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,
or support my work at <https://liberapay.com/yantar92>

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.