A few things caused some confusion while reading the post.
For the first 50,000 cells flame graph, the post identifies two methods as the main time sinks, com.itextpdf.layout.renderer.TableBorderUtil#createAndFillBorderList and com.itextpdf.layout.renderer.CollapsedTableBorders#getCollapsedList.
I looked for those two methods in the flame graph and couldn't find them.
Only when I realized that the flamegraph had truncated the full method names to show just the method name, did the graph make sense.
I think circling in red (or whatever high contrast colour you want) the method names in the flame graph would've made drawing attention to them much quicker.
The second problem is a display problem.
The third table, displaying the results of post-optimization for collapsed table borders only displays three columns on Firefox (hiding the fourth column, containing the post-optimization runtimes). If the user moves the mouse over the table, then the horizontal scrollbar for the table appears, hinting that there's more data hidden off the right end of the table.
The third quibble I have with the post is the display of large numbers in the tables. Actually the last table fixed the problem, using '_' as a thousands digit separator. If that change could be applied to the other tables in the post, that'd make discerning the differences in runtimes easier.
It's funny that iText is still around. I used this 20 years ago in a hybrid .NET/Java web app that needed a PDF renderer and it was pretty much the top choice. The rendering still looks the same!
It's standard practice to take those kinds of numbers out of title, because they make the title more baity, and often cause much of the discussion to focus on debate about how accurate/normal the figure is. It's sufficient for the title to say "faster" then let the article demonstrate how much faster it can be in different scenarios.
canucker2016|9 months ago
A few things caused some confusion while reading the post.
For the first 50,000 cells flame graph, the post identifies two methods as the main time sinks, com.itextpdf.layout.renderer.TableBorderUtil#createAndFillBorderList and com.itextpdf.layout.renderer.CollapsedTableBorders#getCollapsedList.
I looked for those two methods in the flame graph and couldn't find them.
Only when I realized that the flamegraph had truncated the full method names to show just the method name, did the graph make sense.
I think circling in red (or whatever high contrast colour you want) the method names in the flame graph would've made drawing attention to them much quicker.
The second problem is a display problem.
The third table, displaying the results of post-optimization for collapsed table borders only displays three columns on Firefox (hiding the fourth column, containing the post-optimization runtimes). If the user moves the mouse over the table, then the horizontal scrollbar for the table appears, hinting that there's more data hidden off the right end of the table.
The third quibble I have with the post is the display of large numbers in the tables. Actually the last table fixed the problem, using '_' as a thousands digit separator. If that change could be applied to the other tables in the post, that'd make discerning the differences in runtimes easier.
Thanks
mmastrac|9 months ago
nine_k|9 months ago
Dear @dang, may we have the "95%" back?
tomhow|9 months ago
comrade1234|9 months ago
[deleted]