-
Notifications
You must be signed in to change notification settings - Fork 27
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
Avoid copies when passing binary parameters #22
Conversation
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.
This PR does multiple things at once. Please split.
There were two identical copies each of the parameter mangling code.
Instead of building a list of 'Int' in the fold, and then mapping 'toEnum' over it, build a list of 'CInt' directly.
We encode various arrays of the same length through 'withArray'. Each of these computes the length, so we might as well take the length from one of these.
I've split out the first commit in #23, will file follow-up PRs if/as that one gets merged. |
Apologies for the re-review request, meant to request review for #23. |
Did you see #23? Is that what you had in mind? |
Sorry, that's because I was repurposing the branch to file a PR against a fork of this repo. Closing. |
fork? interesting... |
There's no desire to fork, I just want to move forward with this in PostgREST in some way, and the best choice seems to be to build against a (hopefully temporary) fork. Some discussion over here if you're interested: PostgREST/postgrest#2422 |
Currently, the library copies every input parameter when passing it to libpq via
Data.ByteString.useAsCString
. This PR avoids those copies for the case of binary parameters, by usingData.ByteString.Unsafe.unsafeUseAsCString
.I claim that this is safe because:
ByteString
uses pinned memoryThere are a few preparatory commits to factor out duplicate code to
withParams
, and to avoid a bit of unnecessary work there.Context is PostgREST/postgrest#2261. We see significant decrease of memory use with this change: PostgREST/postgrest#2349