-
Notifications
You must be signed in to change notification settings - Fork 10.5k
[benchmark] Fix spurious benchmark regressions #39340
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
Conversation
@swift-ci benchmark |
@swift-ci smoke test |
Performance (x86_64): -O
Code size: -O
Performance (x86_64): -Osize
Code size: -Osize
Performance (x86_64): -Onone
Code size: -swiftlibsHow to read the dataThe tables contain differences in performance which are larger than 8% and differences in code size which are larger than 1%.If you see any unexpected regressions, you should consider fixing the Noise: Sometimes the performance results (not code size!) contain false Hardware Overview
|
Ah, it looks like in smoke tests Linux bots are just running the benchmark executable directly.
|
@swift-ci benchmark |
@swift-ci smoke test |
Performance (x86_64): -O
Code size: -O
Performance (x86_64): -Osize
Code size: -Osize
Performance (x86_64): -Onone
Code size: -swiftlibsHow to read the dataThe tables contain differences in performance which are larger than 8% and differences in code size which are larger than 1%.If you see any unexpected regressions, you should consider fixing the Noise: Sometimes the performance results (not code size!) contain false Hardware Overview
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Nice find.
The benchmark driver accidentally fails to set the
SWIFT_DETERMINISTIC_HASHING
environment variable for its subprocesses, which means that hashed collections have far more performance variance than expected.I think the recent plague of flaky benchmark results (especially
DictionaryOfAnyHashableStrings_insert
) has been due to this issue.Additionally, update CMake to postprocess the benchmark executables with
swift-darwin-postprocess.py
to work around a dyld issue on macOS Monterey that makes the benchmark executable fail with spurious unknown selector exceptions.