-
Notifications
You must be signed in to change notification settings - Fork 183
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
Make list_formatter data *almost* zero-copy #1680
Conversation
Perhaps we can make an upstream contribution to make the verification be zero-alloc.
Alternatively, could we add a flag to weaken the assertion from total bytes the same to current bytes the same, allowing for intermediate allocations during the deserialization process? |
I was thinking about that, I kinda prefer us obviating all allocations but I'm not against sticking to the "current" thing. As far as upstream goes, I had a look, the problem is that they need to allocate a BTreeMap to do the check. Maybe there's a way around it. |
We should enforce "no allocations whatsoever" by default, but switching to "no net allocations" could be an alternative to the allowlist. |
sounds good, I've already updated that PR so that it measures both (but still uses total) We should get that landed and iterate on that allowlist here |
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.
Ah good catch, we wouldn't have noticed this if we just checked for borrow annotations.
(or get this landed first and add the allowlist there, either works for me) |
Notice: the branch changed across the force-push!
~ Your Friendly Jira-GitHub PR Checker Bot |
@sffc We now have two allowlists here |
Notice: the branch changed across the force-push!
~ Your Friendly Jira-GitHub PR Checker Bot |
Unfortunately, this cannot be 100% non-allocating due to the
DFA::from_bytes()
used for verification. I'm not sure what to do about that, technically the data is still zero-copy (and this can be done in a crab-bake-kosher way) but our tool will still complain.Might be worth allowlisting it for allocating exactly 1408 bytes.
Part of #1678