Skip to content

Eliminate the parallelization overhead when not needed#5538

Open
xificurk wants to merge 2 commits intophpstan:2.1.xfrom
xificurk:optimize-parellalization
Open

Eliminate the parallelization overhead when not needed#5538
xificurk wants to merge 2 commits intophpstan:2.1.xfrom
xificurk:optimize-parellalization

Conversation

@xificurk
Copy link
Copy Markdown

The main target of this optimization is partial analysis run with a small number of files.

In my test runs with single file analyzed, it cuts down the total time almost in half (8.9 s -> 5.0 s).

Note this actually reverts commit 2159057 (Run the parallel worker even for a low number of files) - I am not sure, what the motivation has been then.

@phpstan-bot
Copy link
Copy Markdown
Collaborator

You've opened the pull request against the latest branch 2.2.x. PHPStan 2.2 is not going to be released for months. If your code is relevant on 2.1.x and you want it to be released sooner, please rebase your pull request and change its target to 2.1.x.

Revert "Run the parallel worker even for a low number of files"

This reverts commit 2159057.
@xificurk xificurk force-pushed the optimize-parellalization branch from 16c8e91 to c4db303 Compare April 26, 2026 08:58
@xificurk xificurk changed the base branch from 2.2.x to 2.1.x April 26, 2026 08:59
@staabm staabm requested a review from ondrejmirtes April 26, 2026 10:20
@ondrejmirtes
Copy link
Copy Markdown
Member

The current code is important so that every analysis runs in a child worker. It means we will get a nice output even if the analysis in the worker crashes.

Addressing the root cause (the overhead you get for running a child worker) is really important here. It'd mean the analysis gets faster for everyone. Instead of working around it and run the analysis in the main thread. So if you're experiencing overhead, it'd be great to profile it with Blackfire or similar and make the code faster, or skip something that it doesn't have to do at all.

Again, to repeat my usual point, it's best to analyse the whole project instead of select files.

@xificurk
Copy link
Copy Markdown
Author

Addressing the root cause (the overhead you get for running a child worker) is really important here. It'd mean the analysis gets faster for everyone. Instead of working around it and run the analysis in the main thread. So if you're experiencing overhead, it'd be great to profile it with Blackfire or similar and make the code faster, or skip something that it doesn't have to do at all.

I can try dig into this more, but the bottom line is that there will always be some cost for the orchestration of child workers - the subprocess management is not free and never will be. So, I wouldn't call this a workaround - when analyzing just a few files skipping the subprocess management falls exactly into the category "skip something that it doesn't have to do at all".

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants