-
Notifications
You must be signed in to change notification settings - Fork 93
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
perf(ts): reuse Reader whilst parsing records #1212
Conversation
This is both a refactor and perf boost, with more room for improvement, key changes: - Removes StreamBuffer, hoisted into McapStreamReader - Reuses Reader and DataView class across parse calls, only resetting them when necessary (e.g: append in McapStreamData) - Splits `parseRecord` into small scoped parsing functions, this itself is perf neutral (slightly positive) but facilitates future monomorphic fast paths - Moves offsets tracking into Reader which is cleaner and faster
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Seems like a nice refactor overall! Most of it makes sense to me, I just left a few questions and cleanup suggestions. I do find the duplication of reader.offset = startOffset + recordLength;
a bit repetitive and I wonder if there is a way that could be cleaned up...
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think it's a bit of a shame to lose these tests, but I guess the thinking is that the StreamReader is already pretty well tested?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Would it be covered by all the conformance testing? These tests seem really specific to this now deleted class so seems ok?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@defunctzombie I think this is exercised/covered by comformance testing since at least one of those tests reads/streams byte-by-byte. Exercising the appendOrShift.
Now that it's scoped out and #appendOrShift
was the only important part, I think it could be fair to split that out into a function and test in isolation.
// eslint-disable-next-line @foxglove/no-boolean-parameters | ||
validateCrcs: boolean, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
same comment about boolean parameters applies here
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Would it be covered by all the conformance testing? These tests seem really specific to this now deleted class so seems ok?
const headerReader = new Reader( | ||
new DataView(headerRecord.buffer, headerRecord.byteOffset, headerRecord.byteLength), | ||
); | ||
const headerResult = parseRecord(headerReader, true); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
const headerResult = parseRecord(headerReader, true); | |
const validateCrcs = true; | |
const headerResult = parseRecord(headerReader, validateCrcs); |
Nit, makes it a bit more readable
} | ||
|
||
function parseSchema(reader: Reader, recordLength: number): TypedMcapRecord { | ||
const start = reader.offset; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
nit: Rename to startOffset
to stay consistent with other parse*
functions
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks good, but before merging please add a comment to explain the disabling of the no-boolean-parameters lint rule (see #1212 (comment) and also consider this suggestion: #1212 (comment))
### Changelog Performance improvements (#1212)
This reverts commit 4fcdd33.
Reverts #1212 This broke streaming in Foxglove app. Until we can investigate we need to put the library back to a working state.
Reduces `McapStreamReader` heap usage by ~25% and boosts throughput by ~30%. This is both a refactor and perf boost, with more room for improvement, key changes: - Removes StreamBuffer, hoisted into McapStreamReader - Reuses Reader and DataView class across parse calls, only resetting them when necessary (e.g: append in McapStreamReader) - Splits `parseRecord` into small scoped parsing functions, this itself is perf neutral (slightly positive) but facilitates future monomorphic fast paths - Moves offsets tracking into Reader which is cleaner and faster ### Before ``` McapStreamReader 3.48±0.03 op/s Heap Used: 49.56±12.75 MB/op Heap Total: 41.47±11.83 MB/op ArrayBuffers: 112.95±6.87 MB/op McapIndexedReader 2.15±0.02 op/s Heap Used: 70.02±2.84 MB/op Heap Total: 58.34±3.36 MB/op ArrayBuffers: 17.86±0.76 MB/op McapIndexedReader_reverse 2.18±0.01 op/s Heap Used: 59.92±2.86 MB/op Heap Total: 39.81±1.00 MB/op ArrayBuffers: 14.58±1.42 MB/op ``` ### After ``` McapStreamReader 4.47±0.08 op/s Heap Used: 42.35±2.23 MB/op Heap Total: 32.93±3.76 MB/op ArrayBuffers: 105.93±12.19 MB/op McapIndexedReader 2.38±0.02 op/s Heap Used: 72.00±1.70 MB/op Heap Total: 55.12±2.51 MB/op ArrayBuffers: 17.86±1.85 MB/op McapIndexedReader_reverse 2.38±0.02 op/s Heap Used: 63.41±1.55 MB/op Heap Total: 39.33±0.53 MB/op ArrayBuffers: 18.40±1.60 MB/op ``` ### Followups - Simplify parsing code further after exploring monomorphic callpaths - Can further improve DataView/Reader churn in indexed readers
### Changelog Typescript: Performance improvements for readers ### Docs None ### Description Reintroduces the changes made in #1212, which have been reverted in #1227, with an additional fix & test (separate commit) for the buffer append logic. The original code of #1212 removed the `streamBuffer` object and implemented the buffer append ing logic directly in the `McapStreamReader` class. The append logic had a bug which caused existing data to be partially overridden by new data. From #1212: > Reduces `McapStreamReader` heap usage by ~25% and boosts throughput by ~30%. > > This is both a refactor and perf boost, with more room for improvement, key changes: > - Removes StreamBuffer, hoisted into McapStreamReader > - Reuses Reader and DataView class across parse calls, only resetting them when necessary (e.g: append in McapStreamReader) > - Splits `parseRecord` into small scoped parsing functions, this itself is perf neutral (slightly positive) but facilitates future monomorphic fast paths > - Moves offsets tracking into Reader which is cleaner and faster > > ### Before > > ``` > McapStreamReader > 3.48±0.03 op/s Heap Used: 49.56±12.75 MB/op Heap Total: 41.47±11.83 MB/op ArrayBuffers: 112.95±6.87 MB/op > McapIndexedReader > 2.15±0.02 op/s Heap Used: 70.02±2.84 MB/op Heap Total: 58.34±3.36 MB/op ArrayBuffers: 17.86±0.76 MB/op > McapIndexedReader_reverse > 2.18±0.01 op/s Heap Used: 59.92±2.86 MB/op Heap Total: 39.81±1.00 MB/op ArrayBuffers: 14.58±1.42 MB/op > ``` > > ### After > > ``` > McapStreamReader > 4.47±0.08 op/s Heap Used: 42.35±2.23 MB/op Heap Total: 32.93±3.76 MB/op ArrayBuffers: 105.93±12.19 MB/op > McapIndexedReader > 2.38±0.02 op/s Heap Used: 72.00±1.70 MB/op Heap Total: 55.12±2.51 MB/op ArrayBuffers: 17.86±1.85 MB/op > McapIndexedReader_reverse > 2.38±0.02 op/s Heap Used: 63.41±1.55 MB/op Heap Total: 39.33±0.53 MB/op ArrayBuffers: 18.40±1.60 MB/op > ``` --------- Co-authored-by: Aaron O'Mullan <[email protected]>
Reduces
McapStreamReader
heap usage by ~25% and boosts throughput by ~30%.This is both a refactor and perf boost, with more room for improvement, key changes:
parseRecord
into small scoped parsing functions, this itself is perf neutral (slightly positive) but facilitates future monomorphic fast pathsBefore
After
Followups