Re: [PATCH] (x)memcoll: performance improvement when input is known to be NUL delimited.

[Chen Guo]

Hi Padraig,
    Thanks for the _unlikely insight, that explains why it's not slower
but the speed up is still quite mysterious. When I ran with the line
lengths you wanted, with check it is no longer faster, but something
else I don't quite understand pops up.

    The file I usually test on is 1M lines, 98 bytes each not counting
newline. Average of5 runs:

Without check: ~5.10
With check: ~5.08

Which is as I described last time. I then generated files with lines of
32, 33, 64, 65 bytes (the machine is 64 bits). This doesn't include the
newline byte. The results looked odd so I did more runs, with 31, 63,
and 66.

With check:
31: ~4.02
32: ~4.37
33: ~4.28
63: ~4.44
64: ~4.77
65: ~4.68
66: ~4.81

Without check:
31: ~4.04
32: ~4.36
33: ~4.28
63: ~4.44
64: ~4.75
65: ~4.67
66: ~4.79

So here at least without check is slightly faster, as expected,
but for some reason the speeds go like 66 > 64 > 65, instead
of 66 > 65 > 64.

I was curious exactly when running with the check became
faster, but pretty soon realized I could be doing this all day.
Here's how far I got:
97 bytes:
with: ~5.15
w/o: ~5.18

96 bytes: 
with: ~5.22
w/o: ~5.25

95 bytes:
with: ~4.97
w/o: ~4.96

94 bytes:
with: ~5.19
w/o: ~5.20

93 bytes:
with: ~5.09
w/o: ~5.10

Normally I'd discount .01s, but in this case, everything from
93 - 98 except 95 is faster with the check, the difference is
highest at 96-98 bytes, and for each case the difference
between the fastest and slowest runs was 0.02s. I would say
this is beyond coincidence.

When I get some time I'll use binary search to find exactly
where between 66 and 93 bytes the version with the check
gets faster... Maybe that'll give us a clue why, unless from
the above results you guys have some intuition as to the cause.