`tb.toString()` performance
See original GitHub issueHello, I found that when the number of rows is huge, I start to have some performance problems.
I have 1763 rows (5 columns) and it takes me 4473.023ms to run toString
method, I want to know if there is a way to improve the performance ?
Thank you!
Issue Analytics
- State:
- Created 5 years ago
- Comments:5 (2 by maintainers)
Top Results From Across the Web
Best practice or performance difference between ToString ...
When I am concatenating object values together to form a string in VB.NET, is there a difference in performance or a recommended best...
Read more >Who Cares About toString Performance? - Antonio's Blog
Check the average performance with JMH in the comments below: [sourcecode language=”java”] public String toString() { return “MyObject{” +
Read more >National TB Performance Targets | Resources & Tools - CDC
National TB Performance targets are measurable and aspirational and are intended to be used by TB programs to assess their level of performance...
Read more >org.basex.util.Performance.getTime java code examples | Tabnine
@Override public String toString() { return getTime(); } } ... getTime(parsing, runs)).add(NL); tb.add(COMPILING_CC).add(Performance.
Read more >On the Virtues of Avoiding Parsing or Basing Logic on toString ...
For example, using the results of a toString() call in Java to make a ... Similarly, the 1988 made-for-TV version of Rear Window...
Read more >
Top Related Medium Post
No results found
Top Related StackOverflow Question
No results found
Troubleshoot Live Code
Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start Free
Top Related Reddit Thread
No results found
Top Related Hackernoon Post
No results found
Top Related Tweet
No results found
Top Related Dev.to Post
No results found
Top Related Hashnode Post
No results found
Pending #278, which is intended to resolve a layout bug, includes some performance gains that can be furthered.
After doing some further benchmarking, I believe it might be possible to get the layout rending of 100k cells to under or around 2 seconds—which might get close to “as good as it gets”, or, roughly, a 3,600% decrease in rendering time at the least. Rendering 10k cells, would be well below 1 second (depending on table complexity).
Insofar, only the
layoutTable()
function has been refactored yet all of the makeTableLayout() function can likely be accomplished in a single pass over the table. Presently it’s traversing the table 4+ times with some “exponential looping” remaining infillInTable()
,addRowSpanCells()
, andaddColSpanCells()
.I haven’t written many performance tests, but think I’ll take a stab at it. My hunch is to attempt to test for a time increase exceeding a threshold on nominally sized tables rather than rendering large tables and testing that they rendered within a fixed threshold. I’ll try to post a PR with failing tests when I’ve got one and work from there!
With the release of 0.6.2 and #278, the performance of cli-table3 should noticeably increase for nearly all large tables—while even small tables will render in substantially less time at a micro level.
Using the performance testing tool at #294, rendering-time for a
1,763 x 5
table has decreased from the stated 4.5 seconds to approximately 0.5 seconds.While this is 800% better, and likely sufficient in most cases, the memory consumption is still terrible and there is another ~2,500% decrease in rendering time that can be had!
Update to v0.6.2+ for these (initial) performance enhancements.