On Tue Mar 27 21:09:06 2012, SPROUT wrote:
Show quoted text> I was testing various modules against 5.15.9 when I noticed that
> Dancer’s
> t/03_route_handler/03_routes_api.t would always hang. It turns out to
> be using an inefficient
> regular expression which hangs when the string is long, in Error.pm:
>
> $content =~ s{(\s*)(\S+)(\s*)=>}{$1<span class="key">$2</span>$3
> =>}g;
>
> I tried making this change:
>
> --- lib/Dancer/Error.pm 2012-01-28 14:52:43.000000000 -0800
> +++ blib/lib/Dancer/Error.pm 2012-03-27 18:00:20.000000000 -0700
> @@ -126,6 +126,7 @@ sub dumper {
> my $dd = Data::Dumper->new([\%data]);
> $dd->Terse(1)->Quotekeys(0)->Indent(1);
> my $content = $dd->Dump();
> +warn $content;
> $content =~ s{(\s*)(\S+)(\s*)=>}{$1<span class="key">$2</span>$3
> =>}g;
> if ($censored) {
> $content
>
> and then re-running the test. The regexp is getting stuck on the
> output shown below. I
> haven’t really looked at the regexp to see how it could be improved,
> but I know it’s not a
> regression in 5.15.9, as 5.14.2’s regexp engine has the same
> difficulty.
The (\s*) at the beginning of the regexp does not need an asterisk. Wrapping the \S+ in an
atomic group stops perl from backtracking into it when => isn’t found (when it’s searching
through the value, rather than the name, of an env var).
See the attached patch, which really speeds this up.