Skip to content
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

[SR-9184] UTF-8 String Regressions #51675

Open
milseman mannequin opened this issue Nov 5, 2018 · 4 comments
Open

[SR-9184] UTF-8 String Regressions #51675

milseman mannequin opened this issue Nov 5, 2018 · 4 comments
Assignees
Labels
performance standard library Area: Standard library umbrella task

Comments

@milseman
Copy link
Mannequin

milseman mannequin commented Nov 5, 2018

Previous ID SR-9184
Radar None
Original Reporter @milseman
Type Task

Attachment: Download

Additional Detail from JIRA
Votes 0
Component/s Standard Library
Labels Task, Performance
Assignee @milseman
Priority Medium

md5: 5e76fa6a2d0620628262e8b5de6feea2

Sub-Tasks:

  • SR-9192 Flatten/rework normalized code unit iterator
  • SR-9212 String comparison binary-divergence fast-path not triggering
  • SR-9270 Tweak String comparison inlinability
  • SR-9272 Potential invalid benchmarks (used to skip allocations)
  • SR-9287 Poor codegen for String iteration
  • SR-9427 CharacterLiteralsSmall: Failure to constant-fold release

Issue Description:

UTF-8 String comes a lot of wins, but some current regressions:

regressions.md

This is an ☂️ bug, see Sub-Tasks below.

Current status of this set of regressions. Note this is only a listing of what were regressions when the PR was merged; omitted benchmarks exhibited improvement:

  • 5.0 currently has parity with 4.2 performance:

    • StringFromLongWholeSubstringGeneric

    • StringComparison_fastPrenormal

    • WordCountUniqueASCII

    • RemoveWhereQuadraticString

    • StringWordBuilder

    • StringHashing_ascii

  • 5.0 is faster than 4.2:

    • SubstringComparble

    • StringFromLongWholeSubstring

    • StringComparison_latin1

    • StringWalk

    • StringEqualPointerComparison

    • Dictionary3

    • StringWordBuilderReservingCapacity

    • StringHasPrefixUnicode

    • Dictionary

    • RemoveWhereFilterString

    • StringInterpolationManySmallSegments

    • StringMatch

    • Join

    • StringBuilderLong

    • RomanNumbers

  • Resolved for Swift 5.0:

    • Chars2: We're happy with the size/speed tradeoff

      • While still slower than 4.2, this is now is significantly smaller in code size (~7x smaller)

Every single one of these extracted and merged into a single script file normalized to around 1 second each: https://gist.github.com/milseman/737d74fd4a6817432b3b5f18c34d416d

@milseman
Copy link
Mannequin Author

milseman mannequin commented Nov 16, 2018

Ok, so JIRA seems to just drop all my carefully set hyperlinks whenever I edit the description...

@palimondo
Copy link
Mannequin

palimondo mannequin commented Dec 6, 2018

@milseman Re: "Every single one of these …"
I see these contain stuff from StringWalk.swift (CharIndexing*, CharIteration* and StringWalk* families). I was about to enable all of these benchmarks (analogous to Existential Redux) of these after adjusting for correct fast runtimes and renaming to match proposed naming convention. Can I do that, or are you already working on these?

@milseman
Copy link
Mannequin Author

milseman mannequin commented Dec 6, 2018

Go ahead! I may merge several of them together in the future; as we add more fast-paths they all start to measure the same fast-paths.

@milseman
Copy link
Mannequin Author

milseman mannequin commented Dec 6, 2018

CC @airspeedswift @eeckstein, as I'm using this to track the remaining String regressions.

@swift-ci swift-ci transferred this issue from apple/swift-issues Apr 25, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
performance standard library Area: Standard library umbrella task
Projects
None yet
Development

No branches or pull requests

0 participants