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
I've tried to resist doing this because it causes more work to be done at the time that a catenable builder is constructed, but ultimately, this worth must be done as some point or another. Right now, flattening a catenable builder requires two steps:
Compute the total length
Allocate a byte array and paste the pieces into place
If every builder kept track of its own length, we could get rid of step 1. How should this change be made. Currently, Builder is defined as:
data Builder = Builder Int Body
data Body
= Empty
| Cons {-# UNPACK #-} !Bytes {-# UNPACK #-} !Builder
| Snoc {-# UNPACK #-} !Builder {-# UNPACK #-} !Bytes
| Append {-# UNPACK #-} !Builder {-# UNPACK #-} !Builder
That's all it should take. We unpack the length-tracking builders into the body data constructors so that we are not incurring additional indirections. In theory, we could create an unboxed newtype Builder# around a tuple of Int# and Body to guarantee that the builder type didn't cost us additional allocations. But I think GHC can probably do fine without the extra help.
The text was updated successfully, but these errors were encountered:
I've tried to resist doing this because it causes more work to be done at the time that a catenable builder is constructed, but ultimately, this worth must be done as some point or another. Right now, flattening a catenable builder requires two steps:
If every builder kept track of its own length, we could get rid of step 1. How should this change be made. Currently, Builder is defined as:
We need something like this instead:
That's all it should take. We unpack the length-tracking builders into the body data constructors so that we are not incurring additional indirections. In theory, we could create an unboxed newtype
Builder#
around a tuple ofInt#
andBody
to guarantee that the builder type didn't cost us additional allocations. But I think GHC can probably do fine without the extra help.The text was updated successfully, but these errors were encountered: