Skip to content
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): simple monomorphic message parse #1217

Open
wants to merge 1 commit into
base: main
Choose a base branch
from

Conversation

AaronO
Copy link
Contributor

@AaronO AaronO commented Aug 15, 2024

Not fully monomorphic in the parse path, but we still see a ~10% throughput boost for this simple scoped change

Before

McapStreamReader
        4.47±0.09 op/s  Heap Used: 38.73±6.90 MB/op     Heap Total: 30.21±6.23 MB/op    ArrayBuffers: 105.31±12.03 MB/op

After

McapStreamReader
        4.88±0.10 op/s  Heap Used: 37.84±6.64 MB/op     Heap Total: 29.51±6.05 MB/op    ArrayBuffers: 106.73±12.33 MB/op

@defunctzombie
Copy link
Contributor

What makes this monomorphic? What prevents "parse record" from doing similar checks to achieve the same results?

The name of the new function does not line up with the return variable names. Does the function return message records or chunk records? If chunk records then I think it should be named accordingly (if we can't make parseRecord dispatch better). A better comment for the function describing that behavior and when one might prefer it to parseRecord would help capture some of the learnings as well.

@AaronO
Copy link
Contributor Author

AaronO commented Aug 15, 2024

What makes this monomorphic?

That its inputs & outputs are a single shape across calls.

What prevents "parse record" from doing similar checks to achieve the same results?

parseRecord by construction checks opcode and then dispatches to sub-parsers that parse different kinds of messages with varying shapes, it's "megamorphic"

@defunctzombie
Copy link
Contributor

parseRecord by construction checks opcode and then dispatches to sub-parsers that parse different kinds of messages with varying shapes, it's "megamorphic"

And in our case the input is the same (a Reader) but it is the difference in output (aka return value) that causes deoptimization?

@AaronO
Copy link
Contributor Author

AaronO commented Aug 16, 2024

parseRecord by construction checks opcode and then dispatches to sub-parsers that parse different kinds of messages with varying shapes, it's "megamorphic"

And in our case the input is the same (a Reader) but it is the difference in output (aka return value) that causes deoptimization?

Yes return values matter, outputs of one function are inputs to the other. You broadly want as much of your hot path call tree to be as "monomorphic" / specialized as possible.

@AaronO AaronO requested a review from james-rms August 16, 2024 00:36
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Development

Successfully merging this pull request may close these issues.

3 participants