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

Previous Next

Package: emacs;

Reported by: Ihor Radchenko <yantar92 <at> posteo.net>

Date: Tue, 2 May 2023 07:35:02 UTC

Severity: normal

Tags: patch

Full log


Message #53 received at 63225 <at> debbugs.gnu.org (full text, mbox):

From: Mattias EngdegÄrd <mattias.engdegard <at> gmail.com>
To: Ihor Radchenko <yantar92 <at> posteo.net>
Cc: 63225 <at> debbugs.gnu.org
Subject: Re: bug#63225: Compiling regexp patterns (and REGEXP_CACHE_SIZE in
 search.c)
Date: Thu, 4 May 2023 11:24:34 +0200
3 maj 2023 kl. 18.02 skrev Ihor Radchenko <yantar92 <at> 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.





This bug report was last modified 2 years and 37 days ago.

Previous Next


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