-
Notifications
You must be signed in to change notification settings - Fork 10.5k
Add simple benchmarks for JSON coding #20886
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
Add simple benchmarks for JSON coding #20886
Conversation
@swift-ci please smoke benchmark |
@swift-ci please smoke test |
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 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.
Looks like a reasonable start to me. For evolving this in the future, though: what do we directly expect to measure here? Since JSONEncoder
/JSONDecoder
rely on JSONSerialization
, we'll also be picking up any fluctuations there over time; is that acceptable for these benchmarks? Are the tests here intending to measure the cost of the JSON side of things, the Codable
side of things, or both?
(I ask the latter because I've long wanted to introduce a base Encoder
/Decoder
that does nothing but collect an object graph into Swift collections without encoding to any format — ideally allowing us to unit-test/benchmark the Codable
side of things instead of the underlying format.)
var poems = Array(repeating: Jabberwocky(), count: 6) | ||
var encoder: JSONEncoder = JSONEncoder() | ||
var decoder: JSONDecoder = JSONDecoder() | ||
var data: Data! = nil |
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.
Is there a reason to give this a default value?
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.
Probably not
@itaiferber I wanted an end-to-end test so that we can catch regressions on the OS side as well (and just because that's what users actually care about). I agree it would be good to have tests for the individual pieces as well. |
fbdceb6
to
55e74f9
Compare
@swift-ci please smoke benchmark |
@swift-ci please smoke test |
@swift-ci please smoke benchmark |
1 similar comment
@swift-ci please smoke benchmark |
55e74f9
to
4b83778
Compare
@swift-ci please smoke benchmark |
@swift-ci please smoke test |
@Catfish-Man I think you want to do just a plain |
@swift-ci please 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 Noise: Sometimes the performance results (not code size!) contain false Hardware Overview
|
Those numbers look MUCH more stable, excellent |
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 Noise: Sometimes the performance results (not code size!) contain false Hardware Overview
|
4b83778
to
805f82e
Compare
@swift-ci please test and merge |
260c9aa
to
c129066
Compare
@swift-ci please test and merge |
1 similar comment
@swift-ci please test and merge |
This is primitive, but it'll give us a baseline to work from