-
Notifications
You must be signed in to change notification settings - Fork 10.5k
benchmark: add naive string finding #26744
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
45acc7a
to
7f5a834
Compare
6d8b95f
to
7964013
Compare
7964013
to
ad3b3ad
Compare
802afee
to
08da14c
Compare
08da14c
to
8dbd969
Compare
8dbd969
to
84a025e
Compare
84a025e
to
db64d7c
Compare
@swift-ci please benchmark |
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
|
@gottesmm the benchmark is now happy and gives me a green tick. How does this look to you? |
@milseman also turns out that finding a |
@weissi Just squash the commits then LGTM. |
This is most likely because of having to treat CRLF as a single Character. It prevents a lot of the obvious fast paths. |
db64d7c
to
7f9756e
Compare
@gottesmm done, thank you! |
Please don't edit my comments (??) |
So sorry!! I was on my phone as must have clicked 'edit' instead of 'quote reply' and didn't notice :'( |
7f9756e
to
43a1517
Compare
@swift-ci please benchmark |
43a1517
to
8726280
Compare
@swift-ci please benchmark |
Build failed before running benchmark. |
8726280
to
6e5e6c1
Compare
@swift-ci please benchmark |
Build failed before running benchmark. |
FindStringNaive is a simple benchmark which implements a naive String finding algorithm that currently shows a lot of ARC traffic, hopefully to be reduced in the future.
6e5e6c1
to
f758d22
Compare
@swift-ci please benchmark |
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
|
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.
LGTM
@swift-ci please test |
Build failed |
Build failed |
@swift-ci smoke test and merge |
@inline(never) | ||
func runBenchRecursive3ArrayOfUTF8(iterations: Int) { | ||
for _ in 0 ..< iterations { | ||
precondition(findThreeOnUTF8Collection(longArrayFoFoFoFox!, |
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.
@eeckstein @gottesmm Is the use of precondition
here fully equivalent to traditional CheckResults
we use in all other benchmarks?
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.
Yeah, CheckResult is better. It should be slightly less overhead because it's inlinable.
FindStringNaive is a simple benchmark which implements a naive String
finding algorithm that currently shows a lot of ARC traffic, hopefully
to be reduced in the future.
this is a benchmark for https://bugs.swift.org/browse/SR-11335