-
Notifications
You must be signed in to change notification settings - Fork 10.5k
[benchmark] Add HTTP2StateMachine benchmark #19954
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
87af504
to
906a9fc
Compare
@swift-ci please smoke test |
@swift-ci smoke benchmark |
@swift-ci Please smoke test OS X platform |
@swift-ci Please benchmark |
oh sorry, Karoy had already kicked that off :) |
Build comment file:Build failed before running benchmark. |
1 similar comment
Build comment file:Build failed before running benchmark. |
906a9fc
to
0caab21
Compare
@swift-ci please smoke test |
Aww, clearly requires the commit bit. 😞 |
@swift-ci Please smoke benchmark |
Build comment file:Performance: -O
Performance: -Osize
Performance: -Onone
How 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 regressions before you merge the PR. Noise: Sometimes the performance results (not code size!) contain false alarms. Unexpected regressions which are marked with '(?)' are probably noise. If you see regressions which you cannot explain you can try to run the benchmarks again. If regressions still show up, please consult with the performance team (@eeckstein). Hardware Overview
|
0caab21
to
794fea9
Compare
Added a few orders of magnitude. |
@swift-ci Please benchmark |
@swift-ci Please smoke benchmark |
Build comment file:Performance: -O
Performance: -Osize
Performance: -Onone
How 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 regressions before you merge the PR. Noise: Sometimes the performance results (not code size!) contain false alarms. Unexpected regressions which are marked with '(?)' are probably noise. If you see regressions which you cannot explain you can try to run the benchmarks again. If regressions still show up, please consult with the performance team (@eeckstein). Hardware Overview
|
Build comment file:Performance: -O
Performance: -Osize
Performance: -Onone
How 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 regressions before you merge the PR. Noise: Sometimes the performance results (not code size!) contain false alarms. Unexpected regressions which are marked with '(?)' are probably noise. If you see regressions which you cannot explain you can try to run the benchmarks again. If regressions still show up, please consult with the performance team (@eeckstein). Hardware Overview
|
Ok, added two more orders of magnitude. |
794fea9
to
32c366e
Compare
@swift-ci Please smoke benchmark |
Build comment file:Performance: -O
Performance: -Osize
Performance: -Onone
How 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 regressions before you merge the PR. Noise: Sometimes the performance results (not code size!) contain false alarms. Unexpected regressions which are marked with '(?)' are probably noise. If you see regressions which you cannot explain you can try to run the benchmarks again. If regressions still show up, please consult with the performance team (@eeckstein). Hardware Overview
|
@Lukasa This benchmark still seems valuable to have. Could you rebase this patch so we can get it merged? |
32c366e
to
7e82b6f
Compare
@swift-ci please smoke test |
@swift-ci please benchmark |
@CodaFi Sure thing, rebased and resolved the conflicts, and kicked off some tests. |
I don't think that smoke test failure is on me. |
Performance: -O
Code size: -OPerformance: -Osize
Code size: -OsizePerformance: -Onone
Code size: -swiftlibs
How 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
|
@swift-ci test |
⛵ |
This pull request adds a new benchmark to the benchmark suite: HTTP2StateMachine. This benchmark was extracted from work-in-progress code from the SwiftNIO HTTP/2 implementation, and reproduces the core stream state machine that will be used for SwiftNIO's pure-Swift HTTP/2 stack.
This state machine ultimately consists of a moderately-sized enumeration, almost all cases of which contain associated data. Some of this associated data is switched over in some functions, other portions of it are extracted and computed upon in the case bodies.
Why benchmark this?
For SwiftNIO, and network protocol programming in general, it is highly desirable to write protocol implementations that store almost all of their state in associated data of enumerations. This allows the type system to give as much assistance as possible to guaranteeing the correctness of the program.
For this reason, it's important that Swift generates good code for switching over these kinds of enumerations, to avoid providing developers with an incentive to use a less-powerful but faster pattern. Developers are infamous for choosing to do the fast thing instead of the correct thing.
Some quick analysis of the generated assembly for this example reveals that the Swift compiler currently generates pretty good code here, so I think this benchmark is more of a regression test than a target for improvement.
Differences from product code
Int
. These types are ultimatelystruct
s backed byInt32
, so the core layout of the enumeration is not meaningfully different, and I don't think this change will affect the benchmark.switch
statement is contained within ado { } catch
block, which has been removed here. That block does meaningfully affect the complexity of the functions in question, so it may be worth adding it back in: please let me know if that's worthwhile.