have same problem here with phpstan/phpstan (1.10.57) and rector/rector (0.19.5). Timeouts with parallel,Up to 4x slow without parallel

@vinceAmstoutz See rectorphp/rector-src#5477

Let me know if we can improve the feedback 👍

Thank you so much for your input. It help us to improve Rector further and fix the glitch to improve DX for other to come 🙏

@TomasVotruba No, it’s perfect! Thank you so much for all you do for the PHP community 🙏🐘

@vinceAmstoutz See https://github.com/rectorphp/rector-src/pull/5477

Let me know if we can improve the feedback 👍

Thank you so much for your input. It help us to improve Rector further and fix the glitch to improve DX for other to come 🙏

@vinceAmstoutz Thanks for more debug info. Indeed it’s not best practise to use UP_TO_* sets in rector.php longer than is their single-run. They run dozens of rules with very complex logic, as it take to get from Symfony 2 to 7. It’s like running a Tesla control and checking all elements available since the first horse ride 😃

See section 3: https://getrector.com/blog/5-common-mistakes-in-rector-config-and-how-to-avoid-them

I recommend to run those just once and remove those 👍

We got similar feedback from various project, seeing the Symfony “level up to” approach is not the best, neither practical to use. I’ll think about how to deprecate those to avoid similar hustle for other users.

Thank you

Thank you, that seems on specific symfony rules, see changes on latest rector-symfony diffs

https://github.com/rectorphp/rector-symfony/commits/main/

if you found something fishy, feel free to provide a patch 😉

Thank you, at least it faster, I will merge the PR.

I will looking on other area that can improve performance.

Looking at the setlist you have, it seems you have huge of collection of setlist, could you narrow down and possibly found a rules that have bottleneck? Otherwise, we may need a reproducible repo.

@vinceAmstoutz thank you, that’s seems strange, I create a PR to add false default autoload to disable autoload on class_alias at:

• https://github.com/rectorphp/rector-src/pull/5474

for deprecating Rector\Core subnamespace.

Could you try copy src/core_namespace_aliases.php that uses false default autoload at:

https://raw.githubusercontent.com/rectorphp/rector-src/add-false-autoload/src/core_namespace_aliases.php

to your vendor/rector/rector/src/core_namespace_aliases.php and verify if that increase the performance?

@samsonasik So for now, I’ve got these benchmarks to share with you before testing @TomasVotruba suggestions

I also have screenshots of all the measurements I took if you need them.

Thank you, as short, disableParallel() must be compared with same disableParallel() config, and parallel() need to be compared with parallel() config.

I am not sure if I have time to call on this, it is better to have reproducible repo 😃

@vinceAmstoutz Thanks for reaching out. We need to find out what commit caused this.

Could you give this approach a try and see which commit made the performance drop? https://github.com/rectorphp/rector/issues/8403#issuecomment-1893430494

On same disableParallel(), that seems impossible you get 1 minutes as well, while 0.19.x you got 20 minutes.

I guess 1 minutes in previous version 0.18.x, you are using parallel.

Comparing parallel vs disableParallel() is expected got many times slower.

I will 👍

I see. We’ll need to find out, which commit broke this for you, to avoid shooting in the dark.

Could you try few commits before 0.19.0 release and see, how it affects the speed? https://github.com/rectorphp/rector/commits/main/

{
    "require": {
         "rector/rector": "dev-main#dbbdf42842490a97fd9c35e4e899192e1b06f10b"
    }
}

composer update

FYI, i have 681 files and increased timeout by 60 seconds every time it died. It’s working now with 360 seconds. Before, it took about 30 seconds. I looked the release yesterday but don’t find anything yet.

@vinceAmstoutz At first glance it’s suspicious that your process of 800 files times out so soon. To compare Rector codebase has 2100 files and it finishes in about 40 seconds as whole.

If you can provide costly combination of rules and paths, we could look at the performance. We use this approach to find the files and rules - https://tomasvotruba.com/blog/2021/02/01/effective-debug-tricks-narrow-scoping/

I apply some performance improvement on latest dev-main, could you try update to "rector/rector": "dev-main" ?

If still happen, we may need a github repo to reproduce the issue, try use $rectorConfig->disableParallel() to verify the issue on specific rule or in parallel process.