DAVEM TPF grant#2 report #9

I spent this week mostly working on a single ticket,

    RT#120692 Slow global pattern match with input from utf8

The ticket described a performance regression following my recent work on
\G; but in fact it turns out that the bug has always existed in the
optimiser (re_intuit_start()), and my change with \G was just to make it
use the optimiser for the first time. I have a fix worked up it, but
haven't yet pushed it. I plan to audit the code first for similar
problems, which boil down to having to repeatedly calculate the length of
string remaining in chars (i.e. (strend-s) was replaced with
CHR_DIST((U8*)strend, (U8*)s)). This happened below the level of SVs, so
utf8 offset caching wasn't any help.

In the following code, the presence of the utf8 upgrade caused both of the
following regexes to go from milliseconds to 10's of seconds.

    my $s = 'ab' x 1_000_000;
    utf8::upgrade($s);
    1 while $s =~ m/\Ga+ba+b/g;
    $s=~ /^a{1,2}x/ for  1..10_000;



2013/12/09
     2:26 process p5p mailbox
     2:32 RT#120692 Slow global pattern match with input from utf8

2013/12/10
     0:09 process p5p mailbox
     5:09 RT#120692 Slow global pattern match with input from utf8

2013/12/11
     0:11 process p5p mailbox
     3:21 RT#120692 Slow global pattern match with input from utf8

2013/12/12
     0:39 process p5p mailbox
     2:39 RT#120692 Slow global pattern match with input from utf8

2013/12/13
     0:15 process p5p mailbox
     4:14 RT#120692 Slow global pattern match with input from utf8


SUMMARY:
     17:55 RT#120692 Slow global pattern match with input from utf8
      3:40 process p5p mailbox
    ------
     21:35 TOTAL (HH::MM)


-- 
In my day, we used to edit the inodes by hand.  With magnets.

• DAVEM TPF grant#2 report #9 by Dave Mitchell