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

Top Page
Delete this message
Author: ph10
Date:  
To: enh
CC: pcre-dev, Martijn Coenen, Stephen Hines
Subject: Re: [pcre-dev] 3x-4x slowdown in pcre_match
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.

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