-
Notifications
You must be signed in to change notification settings - Fork 46
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
DRAFT: Fast paths for large, native strings #646
base: main
Are you sure you want to change the base?
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. |
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
Processor
surpass the 256-byte size causes significant regressions for some reason. (see milseman#1).The below results are post- #642 and post- #644