speedytwenty
commented
2 years ago The performance tests need to be meaningful as well as reliable—I'm not sure these are reliable as they may be prone to fail and likewise do not test memory usage. I've got a solution that reliably passes these tests in the works but #278 comes much closer for now.
The efforts here should probably supersede 278 for clarity sake, but because some tests might be implicated to really refine performance I'm going to close this PR as it stands as a placeholder in time.
Please examine the failing 12.x build for "benchmarks" of these tests before performance improvements were endeavored.
Following the bug fix in #278, there may be a route to improving table rendering performance as per #68.
This is a first attempt at "performance tests" that attempt to: 1) Fail for the current master 2) Partially pass for #278 3) Fully pass for fully-refactored rendering (in progress)
I did one "fixed" time test of 100k cells. Present master takes approx 72 seconds; 278 takes approx 20 seconds; and once the tests are passing they will consume less than 4 seconds.
The rest of the expectations merely check to ensure that the rendering time is not increasing substantially while a larger table is rendered after and compared with the previous rendering time.