You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
The text was updated successfully, but these errors were encountered:
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
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
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.
When
snoc
ing to aBuilder
which has no right node, instead of allocating a newBuilder
, we could just mutate the currentBuilder
’sArrayBuffer
.We could also add an effectful
preallocate
function which would allow us to grow theBuilder
’sArrayBuffer
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 oneArrayBuffer
and then mutating it. And this would keep the same API, but with addition of apreallocate
function. And we would still get the same performance advantages for doing asubBuilder
with our unbalanced binary tree.The text was updated successfully, but these errors were encountered: