develooper Front page | perl.perl5.porters | Postings from December 2008

Re: 5.10.0 regressions that need fixing

Thread Previous
From:
demerphq
Date:
December 29, 2008 15:24
Subject:
Re: 5.10.0 regressions that need fixing
Message ID:
9b18b3110812291524y4f4a2aefu85e411e017a1f3ea@mail.gmail.com
2008/12/29 Dave Mitchell <davem@iabyn.com>:
> While ploughing through the backlog on my p5p mailbox (I've currently
> worked my way up to 2nd Oct), I've been making a list of bug reports etc
> that seem to indicate a regression between 5.8.8 and 5.10.0, and which
> don't appear fixed yet in bleed and maint-5.10.x.
>
> If anyone has some time spare to fix bugs, these would probably be good
> ones to concentrate on. I'll email out a second list once I've processed
> Oct-Dec.
>
>
> Subject: [perl #50250] perl5.10.0: pos function is much slower with
>        "progressive match" and unicode
>
>    5.10 and bleed very slow on unicode pos()

Ill look into this one.

> Date: Sun, 29 Jun 2008 00:38:27 -0700
> Subject: [perl #56444] Perl 5.10 breaks \N{} in regex interpolated inside regex
>        (with charnames)
>
>    regression since 5.8.x

I think the only way to fix this is to make use of \N{} automatically
load charnames. Otherwise its a necessary consequence of moving the
processing of escape sequences out of the toker and into the regex
engine. IOW, in 5.8 the toker would see \N{blah} and convert it. But
this is problematic in the regex engine as it means that the regex
engine sees the literal and not the escape, which causes problems if
the value is a regex special character. So the toker no longer handles
the conversion, meaning that charnames has to be in scope anywhere
that an embedded pattern using charnames is to be compiled.  The
obvious solution to this is to just make charnames unnecessary, and
make it so using a named \N escape automatically DTRT.

> Date: Fri, 22 Aug 2008 15:28:30 -0700
> Subject: [perl #58280] Speed lost on /^(foo|bar|baz)$/ match
>
>    ((?: open | close | read ) is about 10x slower in 5.10 and bleed
>    compared with 5.8.8

I looked into this. IMO it is a bit of a misrepresentation. The
example given is anchored and the benchmark tests the first
possibility of the alternation, which means that its the case most
likely to show the perl 5.8 engine as fast. When you look into it
deeper the case is murkier. At least half of the performance drop lies
in regex engine start up times, and has nothing to do with the TRIE
code. The remaining drop is due to this case being one where the more
expensive logic of the trie engine is slower than alternation.
However, only trivial changes to the pattern, or the string, result in
quite different results. Ive replied in more detail to the bug
directly. Personally i dont really class this one as a bug tho.

Cheers,
yves

-- 
perl -Mre=debug -e "/just|another|perl|hacker/"

Thread Previous


nntp.perl.org: Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at ask@perl.org | Group listing | About