Add totalSize caching to queue-with-size library #491
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
See the context at: #488 (comment)
domenic
added a commit
that referenced
this pull request
Jan 18, 2017
Previously, we believed that the spec's inefficient-but-clear method, of adding up all the chunk sizes whenever it wanted to get the total queue size, was equivalent to keeping a running count. This was discussed in #582; note also #491 where we changed the reference implementation to the running-count strategy for speed reasons. As discovered in #582 (comment), and further elaborated on in #657, these two methods are not in fact equivalent, due to the vagaries of floating-point arithmetic. (That is, they are equivalent if you assume the addition is floating-point addition, but that is less than clear from the spec.) As such, this commit switches the spec to the more efficient running-count method, as that's realistically the only implementable version. It also adds tests to ensure floating point arithmetic is being used, exposing such cases. This commit also includes a few unobservable cleanups: - It introduces the ResetQueue abstract operation, to ensure that the queue total size gets reset to zero when the queue is cleared. This should not matter because no code paths check the queue's total size after it has been cleared, but keeping the two slots in sync seems virtuous. - It updates the internal slot name for ReadableByteStreamController instances from [[totalQueuedBytes]] to [[queueTotalSize]], to be consistent with those for the other queue-containers. We do not yet use the queue-with-sizes abstract operations (except ResetQueue) on ReadableByteStreamController instances as the queue management is significantly more complicated there. But aligning makes the spec easier to read.
domenic
added a commit
that referenced
this pull request
Jan 18, 2017
Previously, we believed that the spec's inefficient-but-clear method, of adding up all the chunk sizes whenever it wanted to get the total queue size, was equivalent to keeping a running count. This was discussed in #582; note also #491 where we changed the reference implementation to the running-count strategy for speed reasons. As discovered in #582 (comment), and further elaborated on in #657, these two methods are not in fact equivalent, due to the vagaries of floating-point arithmetic. (That is, they are equivalent if you assume the addition is floating-point addition, but that is less than clear from the spec.) As such, this commit switches the spec to the more efficient running-count method, as that's realistically the only implementable version. It also adds tests to ensure floating point arithmetic is being used, exposing such cases. This commit also includes a few unobservable cleanups: - It introduces the ResetQueue abstract operation, to ensure that the queue total size gets reset to zero when the queue is cleared. This should not matter because no code paths check the queue's total size after it has been cleared, but keeping the two slots in sync seems virtuous. - It updates the internal slot name for ReadableByteStreamController instances from [[totalQueuedBytes]] to [[queueTotalSize]], to be consistent with those for the other queue-containers. We do not yet use the queue-with-sizes abstract operations (except ResetQueue) on ReadableByteStreamController instances as the queue management is significantly more complicated there. But aligning makes the spec easier to read. Closes #582. Closes #657.
domenic
added a commit
that referenced
this pull request
Jan 19, 2017
Previously, we believed that the spec's inefficient-but-clear method, of adding up all the chunk sizes whenever it wanted to get the total queue size, was equivalent to keeping a running count. This was discussed in #582; note also #491 where we changed the reference implementation to the running-count strategy for speed reasons. As discovered in #582 (comment), and further elaborated on in #657, these two methods are not in fact equivalent, due to the vagaries of floating-point arithmetic. (That is, they are equivalent if you assume the addition is floating-point addition, but that is less than clear from the spec.) As such, this commit switches the spec to the more efficient running-count method, as that's realistically the only implementable version. It also adds tests to ensure floating point arithmetic is being used, exposing such cases. This commit also includes a few unobservable cleanups: - It introduces the ResetQueue abstract operation, to ensure that the queue total size gets reset to zero when the queue is cleared. This should not matter because no code paths check the queue's total size after it has been cleared, but keeping the two slots in sync seems virtuous. - It updates the internal slot name for ReadableByteStreamController instances from [[totalQueuedBytes]] to [[queueTotalSize]], to be consistent with those for the other queue-containers. We do not yet use the queue-with-sizes abstract operations (except ResetQueue) on ReadableByteStreamController instances as the queue management is significantly more complicated there. But aligning makes the spec easier to read. Closes #582. Closes #657.
domenic
added a commit
that referenced
this pull request
Feb 10, 2017
Previously, we believed that the spec's inefficient-but-clear method, of adding up all the chunk sizes whenever it wanted to get the total queue size, was equivalent to keeping a running count. This was discussed in #582; note also #491 where we changed the reference implementation to the running-count strategy for speed reasons. As discovered in #582 (comment), and further elaborated on in #657, these two methods are not in fact equivalent, due to the vagaries of floating-point arithmetic. (In particular, a is not always equal to a + b - b.) As such, this commit switches the spec to the more efficient running-count method, as that's realistically the only implementable version. This commit also includes a few cleanups in related areas: - It introduces the ResetQueue abstract operation, to ensure that the queue total size gets reset to zero when the queue is cleared. This should not matter because no code paths check the queue's total size after it has been cleared, but keeping the two slots in sync seems virtuous. - It causes the desiredSize getter to always return null for errored streams, and zero for closed streams. - It updates the internal slot name for ReadableByteStreamController instances from [[totalQueuedBytes]] to [[queueTotalSize]], to be consistent with those for the other queue-containers. We do not yet use the queue-with-sizes abstract operations (except ResetQueue) on ReadableByteStreamController instances as the queue management is significantly more complicated there. But aligning makes the spec easier to read. Closes #582. Closes #657.
domenic
added a commit
that referenced
this pull request
Feb 10, 2017
Previously, we believed that the spec's inefficient-but-clear method, of adding up all the chunk sizes whenever it wanted to get the total queue size, was equivalent to keeping a running count. This was discussed in #582; note also #491 where we changed the reference implementation to the running-count strategy for speed reasons. As discovered in #582 (comment), and further elaborated on in #657, these two methods are not in fact equivalent, due to the vagaries of floating-point arithmetic. (In particular, a is not always equal to a + b - b.) As such, this commit switches the spec to the more efficient running-count method, as that's realistically the only implementable version. This commit also includes a few cleanups in related areas: - It introduces the ResetQueue abstract operation, to ensure that the queue total size gets reset to zero when the queue is cleared. This should not matter because no code paths check the queue's total size after it has been cleared, but keeping the two slots in sync seems virtuous. - It causes the desiredSize getter to always return null for errored streams, and zero for closed streams. - It updates the internal slot name for ReadableByteStreamController instances from [[totalQueuedBytes]] to [[queueTotalSize]], to be consistent with those for the other queue-containers. We do not yet use the queue-with-sizes abstract operations (except ResetQueue) on ReadableByteStreamController instances as the queue management is significantly more complicated there. But aligning makes the spec easier to read. Closes #582. Closes #657.
domenic
added a commit
that referenced
this pull request
Feb 10, 2017
Previously, we believed that the spec's inefficient-but-clear method, of adding up all the chunk sizes whenever it wanted to get the total queue size, was equivalent to keeping a running count. This was discussed in #582; note also #491 where we changed the reference implementation to the running-count strategy for speed reasons. As discovered in #582 (comment), and further elaborated on in #657, these two methods are not in fact equivalent, due to the vagaries of floating-point arithmetic. (In particular, a is not always equal to a + b - b.) As such, this commit switches the spec to the more efficient running-count method, as that's realistically the only implementable version. This commit also includes a few cleanups in related areas: - It introduces the ResetQueue abstract operation, to ensure that the queue total size gets reset to zero when the queue is cleared. This should not matter because no code paths check the queue's total size after it has been cleared, but keeping the two slots in sync seems virtuous. - It causes the desiredSize getter to always return null for errored streams, and zero for closed streams. - It updates the internal slot name for ReadableByteStreamController instances from [[totalQueuedBytes]] to [[queueTotalSize]], to be consistent with those for the other queue-containers. We do not yet use the queue-with-sizes abstract operations (except ResetQueue) on ReadableByteStreamController instances as the queue management is significantly more complicated there. But aligning makes the spec easier to read. Closes #582. Closes #657.
domenic
added a commit
that referenced
this pull request
Feb 13, 2017
Previously, we believed that the spec's inefficient-but-clear method, of adding up all the chunk sizes whenever it wanted to get the total queue size, was equivalent to keeping a running count. This was discussed in #582; note also #491 where we changed the reference implementation to the running-count strategy for speed reasons. As discovered in #582 (comment), and further elaborated on in #657, these two methods are not in fact equivalent, due to the vagaries of floating-point arithmetic. (In particular, a is not always equal to a + b - b.) As such, this commit switches the spec to the more efficient running-count method, as that's realistically the only implementable version. This commit also includes a few cleanups in related areas: - It introduces the ResetQueue abstract operation, to ensure that the queue total size gets reset to zero when the queue is cleared. This should not matter because no code paths check the queue's total size after it has been cleared, but keeping the two slots in sync seems virtuous. - It causes the desiredSize getter to always return null for errored streams, and zero for closed streams. - It updates the internal slot name for ReadableByteStreamController instances from [[totalQueuedBytes]] to [[queueTotalSize]], to be consistent with those for the other queue-containers. We do not yet use the queue-with-sizes abstract operations (except ResetQueue) on ReadableByteStreamController instances as the queue management is significantly more complicated there. But aligning makes the spec easier to read. Closes #582. Closes #657.
domenic
added a commit
that referenced
this pull request
Feb 14, 2017
Previously, we believed that the spec's inefficient-but-clear method, of adding up all the chunk sizes whenever it wanted to get the total queue size, was equivalent to keeping a running count. This was discussed in #582; note also #491 where we changed the reference implementation to the running-count strategy for speed reasons. As discovered in #582 (comment), and further elaborated on in #657, these two methods are not in fact equivalent, due to the vagaries of floating-point arithmetic. (In particular, a is not always equal to a + b - b.) As such, this commit switches the spec to the more efficient running-count method, as that's realistically the only implementable version. This commit also includes a few cleanups in related areas: - It introduces the ResetQueue abstract operation, to ensure that the queue total size gets reset to zero when the queue is cleared. This should not matter because no code paths check the queue's total size after it has been cleared, but keeping the two slots in sync seems virtuous. - It causes DequeueValue to ensure that [[queueTotalSize]] never goes negative, despite these issues with floating-point arithmetic. - It causes the desiredSize getter to always return null for errored streams, and zero for closed streams. - It updates the internal slot name for ReadableByteStreamController instances from [[totalQueuedBytes]] to [[queueTotalSize]], to be consistent with those for the other queue-containers. We do not yet use the queue-with-sizes abstract operations (except ResetQueue) on ReadableByteStreamController instances as the queue management is significantly more complicated there. But aligning makes the spec easier to read. Closes #582. Closes #657.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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.
See the context at: #488 (comment)