GNU bug report logs - #51727
add an optional flag to -P to disable JIT

Previous Next

Full log

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

From: Carlo Arenas <carenas <at> gmail.com>
To: Paul Eggert <eggert <at> cs.ucla.edu>
Cc: 51727 <at> debbugs.gnu.org
Subject: Re: bug#51727: add an optional flag to -P to disable JIT
Date: Wed, 10 Nov 2021 04:11:00 -0800

On Tue, Nov 9, 2021 at 4:40 PM Paul Eggert <eggert <at> cs.ucla.edu> wrote:
>
> On 11/9/21 11:04, Carlo Marcelo Arenas Belón wrote:
> > Severity: wishlist
> >
> > There are times, when the expression is too simple or will not be used too
> > often to justify the extra time in -P that is required for JIT compilation.
>
> How much extra time are we talking about? I would expect users would
> bother thinking about this flag only when it significantly helps
> performance, which sorta implies large inputs, which means the
> expression will be used often, which means users won't want to use nojit.

good point; I have to admit its main use, for me at least, was to
actually see how much time I am saving by using jit, and to avoid
hitting buggy jit code paths I might have introduced myself ;), which
is what the commit message kind of implies.

The main point though, was to allow the user the flexibility to decide
for themselves, from any option, while keeping a reasonable default
(which is why keeping JIT enabled by default was done here as well).

> Anyway, if we do this sort of thing I suggest waiting for PCRE2 and
> doing it then. Also, our flags should use the same spelling as PCRE2
> (which suggests that we use 'no-jit' rather than 'nojit').

fair enough, I will make sure to use no-jit if I didn't already.

> And what
> other PCRE2 flags might users want to specify?

a couple that I think might be interesting, is to enable extended
mode, so that users that have really complex expressions can write
them as multiline strings with comments, and one to tell PCRE to skip
the UTF-8 validation if your content is know to be safe, which could
increase performance by more than ~10% if I recall correctly from what
we did in git (which was more aggressive as well and probably didn't
get the results I would expect from grep)

Carlo

Previous Next

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