Closed GUI closed 2 months ago
Thank you very much for the PR! Will try to come to it as soon as possible.
Unfortunately I had to reverse the second commit for v4 of the action. It will be included in v5 as to make it work consistent it will result in some small behavior changes.
thanks again for the great contribution!
This helps improve the performance of this action with two changes:
One of the main slowdowns seems to be in calling
resolvePath()
for each test failure (or for each test ifinclude_passed
is enabled). This function performs file globbing, which appears to be the main bottleneck, but if you have more than 1 failure per file, it's performing the same globbing lookups repeatedly.This introduces a cache so that repeated calls to
resolvePath()
for the same file only needs to perform the globbing once.Another area this optimizes is skipping over additional processing logic for passed tests unless
include_passed
is actually enabled. Previously, various pieces of logic would still be processed for passing tests (like calls toresolveFileAndLine
andescapeEmoji
), even ifinclude_passed
was disabled (the default), so nothing would ever be done with those annotations afterwards. So this optimizes things by never building the annotations to begin with if passed tests are only going to be later ignored.The only behavioral change the test suite picked up related to this (which required a change to the test suite) was the fact that
parseFile
no longer returns annotations for disabled tests by default. But I don't think this actually changes the end behavior of the action, since those disabled tests would then be filtered out afterwards unlessinclude_passed
was explicitly enabled.Benchmarks
I haven't done super rigorous benchmarking, but I was mainly debugging this with a pretty basic test suite with the following numbers of tests:
I was previously using dorny/test-reporter, but I was looking at this action because it did some things differently that I was wanting. However, I noticed the performance differences, and wanted to see if they could be improved.
So with those 579 tests and 11 failures noted above, here were some loose timestamps (according to the GitHub UI) of how long the different actions took to run on 3 separate retry attempts:
dorny/test-reporter
: 1s averagemikepenz/action-junit-report@v4
(before this PR): 9.3s averageGUI/action-junit-report@perf
(after this PR): 2.7s averageI think there's still room for other performance improvements, but I was hoping these couple simpler changes could make a decent difference without changing the behavior or functionality.
Let me know if you have any questions or suggestions. Thanks!