Skip to content

runtime: investigate errorCString benchmark changes #7109

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
josharian opened this issue Jan 13, 2014 · 3 comments
Closed

runtime: investigate errorCString benchmark changes #7109

josharian opened this issue Jan 13, 2014 · 3 comments

Comments

@josharian
Copy link
Contributor

CL 49600043 had a non-trivial impact on some of the map benchmarks. (Perhaps other
benchmarks as well; I only happened to be looking for the regression in -test.bench=Map
in runtime.)

$ benchcmp e373697cd435.txt 884801fb67af.txt
benchmark                              old ns/op     new ns/op     delta
BenchmarkSameLengthMap                 4.42          5.24          +18.55%
BenchmarkMapStringKeysEight_1M         19.0          22.1          +16.32%
BenchmarkMapStringKeysEight_64         19.0          22.1         +16.32%
BenchmarkMapStringKeysEight_32         19.1          22.1      +15.71%
BenchmarkMegMap                        20.3        18.2          -10.34%
BenchmarkMapStringKeysEight_16         20.2          18.5          -8.42%
BenchmarkMegEmptyMap                   3.58          3.30          -7.82%
BenchmarkMapIter                       122           126           +3.28%
BenchmarkMegOneMap                     12.7          13.1          +3.15%


Dave says:

> Looks like code movement/alignment. The first has increased by .8 of ns, another
benchmark has decreased by 1.7ns. I think these numbers are low enough to be in the
noise, but it is concerning. Please consider raising an issue and cc'ing Dmitry to see
if his performance dashboard can corroborate these numbers.


This (rough) delta is very consistent locally for me; I don't believe that it is noise.
Dmitry?
@dvyukov
Copy link
Member

dvyukov commented Jan 13, 2014

Comment 1:

This is not noise (unless computer was busy doing other work). The absolute numbers does
not matter, percents matter.

@dvyukov
Copy link
Member

dvyukov commented Jan 13, 2014

Comment 2:

I also see perf changes after this change:
benchmark                         old ns/op    new ns/op    delta
BenchmarkMegMap                          17           19  +11.86%
BenchmarkMegEmptyMap                      3            3   +8.07%
BenchmarkMapStringKeysEight_32           21           18  -13.55%
BenchmarkMapStringKeysEight_1M           21           18  -13.55%
BenchmarkSameLengthMap                    5            4  -14.54%
Code and data layout are the same, function addresses have changed somewhat.
Some benchmarks become slower, some -- faster. Bigger programs are not visibly affected:
http://goperfd.appspot.com/perfgraph?builder=linux-amd64&builder=windows-amd64&benchmark=garbage&benchmark=json&benchmark=rpc&benchmark=widefinder&procs=1&metric=time&startcommit=1525&commitnum=30&refresh=Refresh
I do not think we need to do anything here.

Status changed to WorkingAsIntended.

@josharian
Copy link
Contributor Author

Comment 3:

Excellent. Thanks for looking at it, Dmitry.

@golang golang locked and limited conversation to collaborators Jun 25, 2016
This issue was closed.
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

No branches or pull requests

3 participants