chore(examples): refresh the benchmark snapshot the decks draw from - #511
Merged
Conversation
The committed snapshot was a single run from 26 July. This is a median of five, taken today, and the decks read it rather than restating it — so refreshing the numbers is this file plus the renders it moves, and no prose changed. The shape is unchanged, which is the point of checking rather than assuming: the time lead over iText widens with size (2.44x at 40 rows, 3.35x at 200, 4.42x at 1000), JasperReports reaches parity at the top size (1.02x), and GraphCompose stays 2.5-2.7x lighter than it on peak heap throughout. Every sentence the decks already carried about those trends is still true of the new figures. All three engines are also about 1.5x faster than in July while peak heap moved under 1%. GraphCompose cannot speed up iText or JasperReports, so that is the machine rather than the code, and it is the reason the pages tell readers to read the ratios rather than the milliseconds. Four committed previews move with it: both decks, the Maven banner and its pptx. The layout baselines do not, and that is worth knowing rather than rediscovering — a ChartNode's box is sized by its spec, so the values inside it change what is painted without moving a single node. Running the snapshot update after a data refresh rewrites the files byte for byte.
This file contains hidden or 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
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
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.
Why
The snapshot both decks and the Maven banner read was a single run from 26 July. This
replaces it with a median of five runs taken today.
What
One data file, and the four committed previews it moves:
engine-deck.pdf,engine-deck-v2.pdf,maven-banner.pdfandmaven-banner.pptx. No prose changed —the pages draw their tables, charts and run metadata from the file, which is what that
design is for.
The numbers still say what the pages say
Checked rather than assumed, because a refresh that quietly invalidates a claim is worse
than a stale one:
All three hold. Every engine is also ~1.5x faster than in July while peak heap moved
under 1% — GraphCompose cannot speed up iText or JasperReports, so that is the machine,
not the code. It is exactly why both pages tell the reader to read the ratios rather than
the milliseconds.
Tests
./mvnw -B -ntp clean verify→BUILD SUCCESS.CommittedAssetDriftTestnamed the fourpreviews that moved before I touched them, and passes after.
One thing worth recording: the layout baselines do not move on a data refresh. I
expected them to and staged them; git showed the files byte-identical. A
ChartNode's boxis sized by its spec —
aspectRatioagainst the available width — so the values insidechange what is painted without moving a node. The baseline holds
CmpCharts, the chart'scontainer, and none of the bars, ticks or labels. So a future snapshot refresh is this
file plus the renders, and nothing else.