Rietveld Code Review Tool
Help | Bug tracker | Discussion group | Source code | Sign in
(344)

Issue 13352045: code review 13352045: sort: use a very fast random generator for benchmarks (Closed)

Can't Edit
Can't Publish+Mail
Start Review
Created:
10 years, 7 months ago by dfc
Modified:
10 years, 6 months ago
Reviewers:
r, rsc, dvyukov
CC:
golang-dev, r
Visibility:
Public.

Description

sort: use a very fast random generator for benchmarks Adapted from https://codereview.appspot.com/11564044. Fixes breakage of darwin-amd64-race builder.

Patch Set 1 #

Patch Set 2 : diff -r 2e89feb1297b https://code.google.com/p/go #

Patch Set 3 : diff -r 2e89feb1297b https://code.google.com/p/go #

Patch Set 4 : diff -r 7f8fb6d64c75 https://code.google.com/p/go #

Unified diffs Side-by-side diffs Delta from patch set Stats (+7 lines, -1 line) Patch
M src/pkg/sort/sort_test.go View 1 1 chunk +7 lines, -1 line 0 comments Download

Messages

Total messages: 10
dfc
Hello golang-dev@googlegroups.com, I'd like you to review this change to https://code.google.com/p/go
10 years, 7 months ago (2013-08-29 01:33:55 UTC) #1
r
LGTM love that generator
10 years, 7 months ago (2013-08-29 01:41:01 UTC) #2
dfc
This helps a bit, not as much as the regexp application, but it might help ...
10 years, 7 months ago (2013-08-29 01:43:55 UTC) #3
dfc
*** Submitted as https://code.google.com/p/go/source/detail?r=4f4edc2ddd93 *** sort: use a very fast random generator for benchmarks Adapted ...
10 years, 7 months ago (2013-08-29 03:21:38 UTC) #4
dfc
Damnit, still too slow *** Test killed with quit: ran too long (10m0s). FAIL regexp ...
10 years, 7 months ago (2013-08-29 05:14:31 UTC) #5
r
instead of fighting it, why not just set a longer timeout?
10 years, 7 months ago (2013-08-29 05:18:32 UTC) #6
dfc
It's a bit tricky, this is the last ditch timeout inside the go process, not ...
10 years, 7 months ago (2013-08-29 05:45:02 UTC) #7
rsc
Why are we running benchmarks on the race detector builder? We don't run them on ...
10 years, 6 months ago (2013-09-05 14:43:20 UTC) #8
dvyukov
On Thu, Sep 5, 2013 at 6:43 PM, Russ Cox <rsc@golang.org> wrote: > Why are ...
10 years, 6 months ago (2013-09-05 14:50:08 UTC) #9
dfc
10 years, 6 months ago (2013-09-11 00:55:45 UTC) #10
I think the issue may have been solved by this CL
https://codereview.appspot.com/13650043 which will prevent benchmarks
running in parallel.

On Fri, Sep 6, 2013 at 12:49 AM, Dmitry Vyukov <dvyukov@google.com> wrote:
> On Thu, Sep 5, 2013 at 6:43 PM, Russ Cox <rsc@golang.org> wrote:
>> Why are we running benchmarks on the race detector builder?
>
> It has uncovered several bugs. E.g. most http benchmarks are not
> concurrent (single request), while benchmarks stress concurrent
> requests.
> Probably it also uncovered some bugs in instrumentation because of
> larger code coverage.
> On the other hand race builders do not run test/api/cgo/etc, so they
> usually finish ahead of normal builders.
>
>> We don't run them on anything else?
>
> dunno
> it may be useful for stability testing
>
>
>> If we have to run benchmarks to exercise more code paths, can't we pass
>> something like -benchtime=0.01s?
>
> We do pass -benchtime=0.01s, or .1s, don't remember exactly.
> There are some benchmarks where 1 iteration takes seconds.
Sign in to reply to this message.

Powered by Google App Engine
RSS Feeds Recent Issues | This issue
This is Rietveld f62528b