On Mon, Sep 26, 2016 at 8:48 PM, Bruce Dubbs <address@hidden> wrote:
...
regexps. First it times the use of a shorter one, then it times the
use of a regexp whose byte count is 10 times larger than the first
one. The test requires that the latter duration be no longer than 20x
the duration of the first run. In your case, it actually took 80ms
longer than the 400ms that would be 20x.
As mentioned in its comments, that test is sensitive to load and
timing. Can you reproduce that failure consistently when running that
test in isolation? I.e., run this a few times:
check -C tests TESTS=long-pattern-perf RUN_EXPENSIVE_TESTS=yes
I may end up changing it to run the quick one 5 times, and use the
minimum time to compare against the duration of the longer-running
command also being run 5 times (or until passing).
Using the above, I ran it about 6 times and it only passed twice. I do have
several apps open but I have 'load average: 0.01, 0.06, 0.05'
$ free
total used free shared buff/cache available
Mem: 8051948 1724040 5279176 414404 1048732 5834340
Swap: 2097148 361760 1735388
Then maybe it's cache effects: much faster with all-in-cache smaller
search string.
Please see if this patch (quadrupling each regexp size) makes it pass
consistently: