-
Notifications
You must be signed in to change notification settings - Fork 650
perf(rome_formater): Inline FormatElement::Text
#3403
Conversation
!bench_formatter |
✅ Deploy Preview for rometools canceled.
|
FormatElement::Text
FormatElement::Text
Formatter Benchmark Results
|
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.
// The position of the dynamic token in the unformatted source code | ||
source_position: TextSize, |
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.
This sounds weird to me.. why a position is a TextSize
and not a TextRange
? (the documentation says range) I would expect a TextSize
to be an offset or an index ... or is it just a misunderstanding of words and we're talking about the same thing?
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.
It's the position where the text starts. The range can be computed by source_position
+ slice.text_len()
Co-authored-by: Emanuele Stoppa <my.burning@gmail.com>
Comparing perf(rome_formater): Inline
1 page tested
|
Chrome Desktop | iPhone, 4G LTE | Motorola Moto G Power, 3G connection |
---|---|---|
Most significant changes
28 other significant changes: JS Parse & Compile on Chrome Desktop, First Contentful Paint on Motorola Moto G Power, 3G connection, Largest Contentful Paint on Motorola Moto G Power, 3G connection, Speed Index on Motorola Moto G Power, 3G connection, Total Page Size in Bytes on Chrome Desktop, Total Page Size in Bytes on iPhone, 4G LTE, Total Page Size in Bytes on Motorola Moto G Power, 3G connection, Number of Requests on Chrome Desktop, Number of Requests on iPhone, 4G LTE, Number of Requests on Motorola Moto G Power, 3G connection, Time to Interactive on Motorola Moto G Power, 3G connection, First Contentful Paint on Chrome Desktop, Time to Interactive on Chrome Desktop, First Contentful Paint on iPhone, 4G LTE, Speed Index on Chrome Desktop, Speed Index on iPhone, 4G LTE, Time to Interactive on iPhone, 4G LTE, Largest Contentful Paint on iPhone, 4G LTE, Total Blocking Time on Motorola Moto G Power, 3G connection, Largest Contentful Paint on Chrome Desktop, Total Image Size in Bytes on Chrome Desktop, Total Image Size in Bytes on iPhone, 4G LTE, Total Image Size in Bytes on Motorola Moto G Power, 3G connection, Total HTML Size in Bytes on Chrome Desktop, Total HTML Size in Bytes on iPhone, 4G LTE, Total HTML Size in Bytes on Motorola Moto G Power, 3G connection, Lighthouse Performance Score on Motorola Moto G Power, 3G connection, Lighthouse Performance Score on Chrome Desktop
Calibre: Site dashboard | View this PR | Edit settings | View documentation
Summary
This PR inlines the
Text
enum into theFormatElement
enum to reduce the size ofFormatElement
from 32 to 24 bytes.The largest variant of
FormatElement
isFormatElement::Text
with a size of 24 bytes, which makesFormatElement
32 bytes wide because it adds one byte for the variant tag + 7 bytes of padding.The size of
Text
is 24 bytes:SyntaxTokenText
:GreenToken
+ 8 bytes for the text range)This means, that we reserve 10 bytes of padding even for the largest enum variant (even worse for e.g.
LineSuffixBoundary
that has 31 bytes of padding).This PR inlines
Text
to avoid having to pad twice, once forText
and once onFormatElement
which results in a size reduction ofFormatElement
to 24 bytes (3 bytes of padding forSyntaxTokenText
).The downside of this change is that matching on text becomes more complicated and it removes the
Eq
implementation that comparedText
by the string content.Test Plan
This change results in a 20% peak memory consumption reduction: Max Bytes: 87.29 MB down to 69.48 MB
Main
This Branch
I expect performance to improve a bit because it reduces the amount of data written during formatting. However, I don't expect too big of an improvement because the size reduction isn't big enough to make 4 format elements fit into a single cache line of 64 bytes (it's now 2 2/3 which probably is of very little use)
Local perf results: