Autor: ph10 Data: A: enh CC: pcre-dev, Martijn Coenen, Stephen Hines Assumpte: 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.