Re: [pcre-dev] 3x-4x slowdown in pcre_match

Looks great, Elliott. Thank you for coming up with the patch.

Steve

On Thu, Apr 16, 2020 at 3:00 PM enh <enh@???> wrote:

> On Thu, Apr 16, 2020 at 8:28 AM <ph10@???> wrote:
> >
> > On Wed, 15 Apr 2020, enh via Pcre-dev wrote:
> >
> > > -PCRE2_SPTR stack_frames_vector[START_FRAMES_SIZE/sizeof(PCRE2_SPTR)];
> > > +PCRE2_SPTR stack_frames_vector[START_FRAMES_SIZE/sizeof(PCRE2_SPTR)]
> > > __attribute__((uninitialized));
> > > mb->stack_frames = (heapframe *)stack_frames_vector;
> > >
> > > i'm happy to try to send you a patch that also includes the relevant
> > > configure "does this compiler have this attribute?" stuff, but thought
> > > i'd check first for your opinions about what naming you'd like to see,
> > > and what you'd like this use-site to look like. just #ifdef
> > > HAVE_ATTRIBUTE_UNINITIALIZED or a PCRE2_KEEP_UNINITIALIZED that
> > > expands to nothing on systems that don't support this.
> >
> > Yes, please. I am a novice at "configure" stuff. Can you do CMake too;
> > if not, perhaps I can figure out what to do. Perhaps set up
> > HAVE_ATTRIBUTE_UNINITIALIZED in config.h (because that is the same as
> > other HAVE_s for the C system), and then define PCRE2_KEEP_UNINITIALIZED
> > in pcre2_internal.h so it keeps the vector definition clean. Does that
> > sound sensible? Thanks.
>
> done. i've attached a patch that includes both the configure and cmake
> bits. i tested both with CC=gcc and CC=clang (for representative
> failure and success cases respectively). sadly i have to mess about
> with -Werror because GCC only warns rather than errors for
> unrecognized attributes by default, but otherwise it's relatively
> straightforward.
>
> > I've just put out a Release Candidate for 10.35; I usually wait a month
> > for comments before the real release, so it should be possible to get
> > this patch in before than.
> >
> > Regards,
> > Philip
> >
> > --
> > Philip Hazel
>