Skip to content
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

Closed
wants to merge 5 commits into from

Conversation

robx
Copy link
Contributor

@robx robx commented Jun 30, 2022

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 using Data.ByteString.Unsafe.unsafeUseAsCString.

I claim that this is safe because:

  • libpq doesn't require binary parameters to be zero-terminated, they are passed with length
  • libpq treats parameter input as read-only
  • ByteString uses pinned memory

There 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

Copy link
Collaborator

@phadej phadej left a 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.

robx added 3 commits July 4, 2022 10:03
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.
@robx robx force-pushed the binary-cstring branch from d82d800 to ed00f57 Compare July 4, 2022 08:20
@robx
Copy link
Contributor Author

robx commented Jul 4, 2022

I've split out the first commit in #23, will file follow-up PRs if/as that one gets merged.

@robx robx requested a review from phadej July 4, 2022 08:21
@robx robx marked this pull request as draft July 4, 2022 08:21
@robx
Copy link
Contributor Author

robx commented Jul 4, 2022

Apologies for the re-review request, meant to request review for #23.

@robx
Copy link
Contributor Author

robx commented Jul 20, 2022

This PR does multiple things at once. Please split.

Did you see #23? Is that what you had in mind?

@phadej
Copy link
Collaborator

phadej commented Sep 5, 2022

@robx
Copy link
Contributor Author

robx commented Sep 5, 2022

Sorry, that's because I was repurposing the branch to file a PR against a fork of this repo. Closing.

@robx robx closed this Sep 5, 2022
@phadej
Copy link
Collaborator

phadej commented Sep 5, 2022

fork? interesting...

@robx
Copy link
Contributor Author

robx commented Sep 5, 2022

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants