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

Improve performance of snoc case by mutating Builder’s ArrayBuffer #4

Open
jamesdbrock opened this issue Jan 25, 2021 · 2 comments
Open

Comments

@jamesdbrock
Copy link
Member

When snocing to a Builder which has no right node, instead of allocating a new Builder, we could just mutate the current Builder’s ArrayBuffer.

We could also add an effectful preallocate function which would allow us to grow the Builder’s ArrayBuffer in advance of doing a lot of snocing, in the event that we have a good idea of how much snocing we're about to do.

So when we're doing a build which involves a lot of snocs of bytes, then instead of allocating a new ArrayBuffer for each byte as we do now, we could get close to the ideal performance case of just allocating one ArrayBuffer and then mutating it. And this would keep the same API, but with addition of a preallocate function. And we would still get the same performance advantages for doing a subBuilder with our unbalanced binary tree.

@jamesdbrock
Copy link
Member Author

Further, if we assume that the user will use preallocate intelligently, and we could grow the buffer in the case of overflow by some small factor like 1.1 instead of the usual 2.0 doubling factor.

@jamesdbrock jamesdbrock changed the title Improve performance of snoc case my mutating Builder’s ArrayBuffer Improve performance of snoc case by mutating Builder’s ArrayBuffer Jan 25, 2021
@jamesdbrock
Copy link
Member Author

This optimization would apply to the put* functions, and it would require the creation of a custom MonadWriter instead of using WriterT, so that we could get mutable access to the Monoid.

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

No branches or pull requests

1 participant