-
Notifications
You must be signed in to change notification settings - Fork 50
DRAFT: Fast paths for large, native strings #646
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
| // return returnValue | ||
| // } | ||
| // | ||
| // } |
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.
TODO: investigate re-enabling this code, or even consider looking at all potential callers of loadScalar.
| return nextByteIdx | ||
| } | ||
| } | ||
| return 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.
TODO: add assertion to check fast-path produces same result as slow path
| } | ||
| return nil | ||
| } // 13-22ms, after: 22-25ms ??? | ||
| // Now down to 3ms |
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.
TODO: remove
|
Not sure why that got marked as a review. Ignore. |
|
Bulk closing old PRs – I'll get this idea re-built on UTF8Span… |
Pulls in a bunch of String-internal bit fiddly code in order to quickly get a pointer to contiguous UTF-8 if we're a (large) native string.
Extract out the Metrics data (unused in release builds), as it seems like having
Processorsurpass the 256-byte size causes significant regressions for some reason. (see milseman#1).The below results are post- #642 and post- #644