Re: [bug-gawk] 4.1.3->4.1.4 = Linux-libre's deblob-check grows huge and takes forever

[arnold]

What happens if you run the test on stock code using LC_ALL=C ?
The original comments imply that dfa was made to work correctly
in multibyte locales. Apparently that assumption isn't correct.
If LC_ALL=C improves performance that's an interesting piece of
evidence.

If we can isolate a particular regex that is causing the hit, the
helpers/dfatest.c program would be useful here to figure out why
and eventually to report it back to the grep / gnulib guys.

In the meantime, a full revert of that change would need to bring
back some of the original comments as well.

Andy --- much thanks for your investigative work. It saved me
a big chunk of time. :-)

Arnold

"Andrew J. Schorr" <address@hidden> wrote:

> On Thu, Jul 13, 2017 at 09:17:23PM -0400, Andrew J. Schorr wrote:
> > I'm double-checking, but the "git bisect" output says:
> > 
> > 92ec6835548d3612bd8f0e6a2b05adf4afb1c581 is the first bad commit
> > commit 92ec6835548d3612bd8f0e6a2b05adf4afb1c581
> > Author: Arnold D. Robbins <address@hidden>
> > Date:   Sun Jul 24 21:44:27 2016 +0300
> > 
> >     Use dfa even in multibyte locales.
> > 
> > :100644 100644 54bd8682476371039888beac851abc40b34b843d 
> > ddf4469ae5a19bc6b0524a5e2aa5ad6d277f0213 M      ChangeLog
> > :100644 100644 0a156ffc3912822b09dfcf5877a6717f81fe5df5 
> > 5049bca6c369dc3b473e5e678af120af20337391 M      re.c
>
> And yes, the attached patch seems to fix the performance regression.
> But I don't understand the deeper issues here about why this change was
> made in the first place. I imagine that there are some cases where this
> was helping performance...
>
> Regards,
> Andy