-
Notifications
You must be signed in to change notification settings - Fork 10.5k
[stdlib] Make some trivial Substring methods inlinable #22616
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
451edf6
to
2c00a23
Compare
This limits future evolution of the standard library. Is there a measurable performance benefit from these changes that justifies any loss in flexibility? |
@milseman should be able to say more about if these were intentionally withheld from inlining (if so, maybe it's worth a comment). I don't know if we actually benchmark these code-paths. I think it's likely going to be worth it to inline the subscript, at least, and |
@karwa the reasoning is usually the other way around: we prefer to not mark something inlinable unless there is sufficient justification. Marking a method inlinable can significantly harm performance, as it will block inlining of non-inlinable code that the method calls. String.replaceSubrange is not inlinable, so making Substring.replaceSubrange is more likely to hurt performance than not. If Substring.replaceSubrange is not inlinable, then String.replaceSubrange can be inlined fully into it. Substring.subscript could be a candidate, as well as the Substring.UTF8View methods. Do you have a benchmark or scenario demonstrating the performance improvement? |
@milseman Nope, I just noticed these while adding I didn't notice that String.replaceSubrange wasn't inlinable. Reverted that change. |
2c00a23
to
ab36b51
Compare
@swift-ci please benchmark |
@milseman Hmm... that doesn't seem to have worked. Mind trying again? |
Performance: -O
Code size: -O
Performance: -Osize
Code size: -Osize
Performance: -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
|
(Just to double check the trend) @swift-ci please benchmark |
@swift-ci please benchmark |
Performance: -O
Code size: -O
Performance: -Osize
Code size: -Osize
Performance: -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
|
Some of those seem spurious, but the CSVParser.UTF8 one doesn't. @swift-ci please benchmark |
Performance: -O
Code size: -O
Performance: -Osize
Code size: -Osize
Performance: -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
|
@milseman what do you think? |
I'm in favor @swift-ci please test |
@swift-ci please test |
Build failed |
@milseman It seems the test was manually aborted:
|
@swift-ci test |
These look like simple oversights.
CC @milseman