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

Add option to launch multiple clang-tidy instances in parallel #81

Open
psalz opened this issue Mar 28, 2023 · 3 comments
Open

Add option to launch multiple clang-tidy instances in parallel #81

psalz opened this issue Mar 28, 2023 · 3 comments
Labels
enhancement New feature or request help wanted Extra attention is needed

Comments

@psalz
Copy link

psalz commented Mar 28, 2023

If a patch touches lots of files the action can actually take quite a while to complete, we are sometimes seeing times upward of 40 minutes. An option to parallelize across input files would therefore be greatly appreciated! It is my understanding that there is already some sort of diagnostic-deduplication happening, so this could probably be applied to duplicate results from parallel execution as well (i.e. for diagnostics generated in shared headers).

@ZedThree
Copy link
Owner

Yes, that would be a nice feature! I think GitHub runners only get something like 2 cores, but that would probably be enough to get a decent speed-up

@ZedThree ZedThree added the enhancement New feature or request label Mar 29, 2023
@vadi2
Copy link
Contributor

vadi2 commented Mar 30, 2023

I've been having a related thought - because github is limited to either 25 comments or 10 annotations, it doesn't always make sense to run clang-tidy over the entire set of changes because that could easily produce far more feedback than github can handle.

In light of this, what about not calling clang-tidy once over the entire set of changes, but strike a middle ground, call it per-file and stop when the output limit is reached?

@psalz
Copy link
Author

psalz commented Apr 3, 2023

In light of this, what about not calling clang-tidy once over the entire set of changes, but strike a middle ground, call it per-file and stop when the output limit is reached?

I'm not sure whether there is any performance benefit to checking multiple files at once instead of one after another, but in general I think that's a good idea, yes! The more substantial changes to the script's logic (invoking clang-tidy multiple times and merging the results) could then probably be shared between these two optimizations.

@ZedThree ZedThree added the help wanted Extra attention is needed label Apr 18, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request help wanted Extra attention is needed
Projects
None yet
Development

No branches or pull requests

3 participants