WIP: experimentally use dupIO (take 2) #321
Draft
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This is an alternative to #319 aimed at fixing #318.
It callsdupIO
on the token stream each time the buffer is full, meaning that any thunks in the old generation will be copied into the new generation relatively quickly, but we do not incur the cost of duplicating thunks more frequently, nor do we need the user/library to insert explicit tokens indicating where to duplicate.(There is no fundamental reason why thedupIO
frequency should be tied to the rate at which the buffer is filled, but it seems like an easy way to implement occasional calls todupIO
. I expect that in most cases the rate of allocatingTokens
constructors should be proportional to the rate at which we run out of space for a new encoded tokens in the buffer.)EDIT: this now calls
dupIO
before evaluating each token in the stream. Testing the above approach on the client's codebase indicated that callingdupIO
only when the buffer is full was not enough to avoid the issue. I've also incorporated a fix to #317, though this doesn't seem to make a massive difference to encoding performance.This still needs
dupIO
to be released, of course.I'm unsure whether this is a good idea in general, since
dupIO
may incur a performance cost of its own. Perhaps it should be guarded by a flag?