Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This is I believe a more correct version of #31 which was attempted and reverted back in 2018. The problem currently is that use of
unsafe.Pointer
leads to cgo defensively inserting calls to this monster: https://github.com/golang/go/blob/master/src/runtime/cgocall.go#L393Aside from the cost of running that code, it also triggers allocations in order to wrap the slice headers into the
any
arguments. This is also the cause of the panics worked around previously in 0ead11aBy passing
char*
rather thanvoid*
we allow cgo to understand that there cannot possibly be any pointers hiding in our data buffers, and skip the checks entirely. In principle this could be applied to every use ofunsafe.Pointer
, but the three updated here seem the most likely cases to be used with small inputs, where the performance effect is noticeable.Before:
After: