runtime/race: regexp benchmarks are too slow under -race build

[davecheney]

What steps will reproduce the problem?
1. ./race.bash on darwin/amd64

What is the expected output? What do you see instead?

expect: Test passes in < 600 seconds
actual: on my core i5 mac mini the test sometimes passes in 580 seconds, but frequently
runs overtime, causing a build failure

Please use labels and text to provide additional information.

http://build.golang.org/log/535d8de6321c1691315bcac0c7100fb4dff9f52c
http://build.golang.org/log/856f79816ce534f99d6482245e4b870b578c6511
http://build.golang.org/log/527bb0c04900433dd52020ae07dd2aa7814678e8
http://build.golang.org/log/a15aafe9bdb68ee56160019ba618eb5405d05416
http://build.golang.org/log/d9d7275b922d324bfe3fd36edce8433d2bb4deb5
http://build.golang.org/log/a477b40776af4f037121c944636f6ae96b35ec1e
http://build.golang.org/log/36b404e7d805015b8108a610ddd26b45f8254e7f

[davecheney]

Comment 2:

Assigning myself as the owner as it's my builder that keeps crashing the party.
When run by itself, this test takes around 400seconds to do a benchmark run 
odessa(~/go/src) % go test -race -run=nothingplease -bench=.* -benchtime=.1s -cpu=4
regexp
PASS
BenchmarkLiteral-4     20000          9639 ns/op
BenchmarkNotLiteral-4       1000        163190 ns/op
BenchmarkMatchClass-4       1000        204425 ns/op
BenchmarkMatchClass_InRange-4       1000        242132 ns/op
BenchmarkReplaceAll-4       2000        124447 ns/op
BenchmarkAnchoredLiteralShortNonMatch-4    50000          6929 ns/op
BenchmarkAnchoredLiteralLongNonMatch-4     50000          7007 ns/op
BenchmarkAnchoredShortMatch-4      10000         19450 ns/op
BenchmarkAnchoredLongMatch-4       10000         20160 ns/op
BenchmarkMatchEasy0_32-4       50000          5029 ns/op       6.36 MB/s
BenchmarkMatchEasy0_1K-4       20000          6328 ns/op     161.80 MB/s
BenchmarkMatchEasy0_32K-4       5000         37633 ns/op     870.71 MB/s
BenchmarkMatchEasy0_1M-4         100       1485220 ns/op     706.01 MB/s
BenchmarkMatchEasy0_32M-4          2      52421638 ns/op     640.09 MB/s
BenchmarkMatchEasy1_32-4       50000          5008 ns/op       6.39 MB/s
BenchmarkMatchEasy1_1K-4        2000         86080 ns/op      11.90 MB/s
BenchmarkMatchEasy1_32K-4        100       2028791 ns/op      16.15 MB/s
BenchmarkMatchEasy1_1M-4           2      66516671 ns/op      15.76 MB/s
BenchmarkMatchEasy1_32M-4          1    2233340980 ns/op      15.02 MB/s
BenchmarkMatchMedium_32-4      20000          8425 ns/op       0.12 MB/s
BenchmarkMatchMedium_1K-4        100       2387800 ns/op       0.43 MB/s
BenchmarkMatchMedium_32K-4         2      74677235 ns/op       0.44 MB/s
BenchmarkMatchMedium_1M-4          1    2501301037 ns/op       0.42 MB/s
BenchmarkMatchMedium_32M-4         1    80536218832 ns/op      0.42 MB/s
BenchmarkMatchHard_32-4     2000        145496 ns/op       0.22 MB/s
BenchmarkMatchHard_1K-4       50       4395453 ns/op       0.23 MB/s
BenchmarkMatchHard_32K-4           1     140574045 ns/op       0.23 MB/s
BenchmarkMatchHard_1M-4        1    4562689670 ns/op       0.23 MB/s
BenchmarkMatchHard_32M-4           1    150848293709 ns/op     0.22 MB/s
ok      regexp  400.504s
it turns out that the -benchtime flag is pointless as it is not consulted til at least
one iteration of the benchmark has been performed. Those iterations take minutes to run. 
The host machine is a SNB core i5, so that is two real cores, and two HT cores (I don't
really know the specifics), so when run concurrently with other benchmarks (sort also
takes minutes) the benchmark time blows out by at least 50% leading to runtimes in
excess of 600 seconds.
The simple answer would be to increase the test timeout a bit, say 800 seconds.

Labels changed: added priority-soon, go1.2, removed priority-triage.

Owner changed to @davecheney.

Status changed to Started.

[remyoudompheng]

Comment 3:

This issue was closed by revision 21b9d14.

Status changed to Fixed.