Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Improve performance of action's processing #1105

Merged
merged 2 commits into from
Jun 20, 2024
Merged

Improve performance of action's processing #1105

merged 2 commits into from
Jun 20, 2024

Conversation

GUI
Copy link
Contributor

@GUI GUI commented Jun 5, 2024

This helps improve the performance of this action with two changes:

  1. One of the main slowdowns seems to be in calling resolvePath() for each test failure (or for each test if include_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.

  2. 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 to resolveFileAndLine and escapeEmoji), even if include_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 unless include_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:

  • 579 tests run
  • 527 passed
  • 41 skipped
  • 11 failed

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 average
    • 1s
    • 1s
    • 1s
  • mikepenz/action-junit-report@v4 (before this PR): 9.3s average
    • 7s
    • 11s
    • 10s
  • GUI/action-junit-report@perf (after this PR): 2.7s average
    • 3s
    • 3s
    • 2s

I 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!

GUI added 2 commits June 4, 2024 21:21
When processing failed test results, this action spent a decent amount
of time in repeated `resolvePath()` calls for the same paths if there
were multiple test failures for the same file path.

This introduces a cache so that repeated calls to `resolvePath()` don't
need to perform the globbing if the same file input is given repeatedly
across multiple tests.
If `include_passed=false` (the default), then the passed tests will
never be used. In that case, we can skip over additional processing of
building annotation data related to these that never ends up getting
used.
@mikepenz
Copy link
Owner

mikepenz commented Jun 5, 2024

Thank you very much for the PR! Will try to come to it as soon as possible.

@mikepenz mikepenz self-requested a review June 5, 2024 06:36
@mikepenz mikepenz merged commit a0437c7 into mikepenz:main Jun 20, 2024
4 checks passed
@mikepenz
Copy link
Owner

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!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants