Re^6: Random data generation.

[furry_marmot]

I think there might be a little bug in salva2. I copied the code from Re^5: Random data generation to try my own solution (middle of the pack, not worth posting), but while studying the code, I noticed a potential problem. my $buf is declared just before gen_salva2.

my $buf;
sub gen_salva2 {
    while (length $buf < $len) {
        $buf .= $set[rand @set] for (1..$len*100);
        $buf =~ s/(.)\1{$max_reps,}/$1 x $max_reps/ge;
    }
    substr($buf, -$len, $len, '');
}

So I put it inside sub gen_salva2{} and ran it again. I bencharked only for $elements = 6, $max_reps = 2, to match BrowserUK's original parameters. That and the change to gen_salva2 are the only changes. Notice how the rankings change.

elements: 6 max_reps: 2
              Rate   salva2     salva almut_mod3 almut_mod4 almut_mod2
+     almut
salva2      1077/s       --      -98%       -98%       -98%       -98%
+      -98%
salva      54086/s    4922%        --       -10%       -13%       -13%
+      -17%
almut_mod3 59766/s    5450%       11%         --        -4%        -4%
+       -8%
almut_mod4 61953/s    5653%       15%         4%         --        -1%
+       -5%
almut_mod2 62270/s    5682%       15%         4%         1%         --
+       -5%
almut      65222/s    5956%       21%         9%         5%         5%
+        --

I thought gen_salva2 got its amazing speed boost by using an already populated $buf. After running the benchmark, I reduced the count to 100 and added a print line before creating $buf to test this theory.

my $buf;
sub gen_salva2 {
    print "$buf\n";
    while (length $buf < $len) {
        $buf .= $set[rand @set] for (1..$len*100);
        $buf =~ s/(.)\1{$max_reps,}/$1 x $max_reps/ge;
    }
    substr($buf, -$len, $len, '');
}

This printed a string 1164 chars long: 4235621656212414423622661645561656223662351124233115.... Each time through, it reduces the length by 12, which is then printed. When the string is too small, it generates a new one. The while() loop is simply not executed very often -- about 1 in 96 to 98 times on average.

--marmot

[salva]

It is not a bug, gen_salva2 is designed to work that way!

$buf is populated by gen_salva2 but instead of generating data for just one output string it generates data for 100 of them (a few less, actually). Next calls to gen_salva2 do not need to fill $buf again as it already contains data (until exhausted, then it is refilled).

That's also the reason my previous comment said it was faster on average!

[furry_marmot]

OOOHHHHhhhhhh... Now I get it. Never mind. :-(