Re: tests/backref-multibyte-slow timeout 5s is too short for my imac 400

[Jim Meyering]

Gilles Espinasse wrote:
> backref-multibyte-slow test fail on my imac 400
> Fail with timeout 5s, pass when timeout is changed to 10s
> I have no faster machine to test on ppc.

Thanks for the report.
What is the ratio of the two times when running the
latest with LC_ALL=en_US.UTF-8 / LC_ALL=C ?
For me, it's approximately 4x, whereas pre-fix, the LC_ALL=en_US.UTF-8
run took 29 times as long as the latest with LC_ALL=C.

$ awk 'BEGIN {for (i=0; i<13000; i++) print "aba"}' /dev/null > in
$ LC_ALL=C           env time --format %e grep -E '^([a-z]).\1$' in > out
0.06
$ LC_ALL=en_US.UTF-8 env time --format %e grep -E '^([a-z]).\1$' in > out
0.23
$ LC_ALL=en_US.UTF-8 env time --format %e /bin/grep -E '^([a-z]).\1$' in > out
6.81

Testing that ratio would be better than using
some arbitrary, absolute limit.
The question is how to do it.

Using Perl would work...
I've wanted this sort of ability for other tests (e.g., coreutils'
tests/rm/ext3-perf), so maybe it's worth adding an option to GNU timeout:
run a reference command, measuring how long it takes, S, and use F*S
as the timeout.  This brings up the issue of whether timeout could take
a floating-point timeout.  I think it should.

Whether this hypothetical version of timeout is installed isn't a big deal.
grep's test script could simply test for the new option and skip
the test if it's not available, just as it currently does if timeout
itself is not installed.  The important thing is that it be installed
by developers, and we can arrange for that.

Pádraig Brady wrote timeout for coreutils, so I've Cc'd him and that list.
Pádraig, what do you think?

Now that I ask that, I think the better approach, for now at least,
is to write a little perl script that does what I'm proposing.