Improve performance of script handlers #12456
Conversation
|
For the case in #8587 (comment), I think another improvement could be done: |
yeah I thought about this but it is most often used for binaries which are anyway now skipping the autoloader completely, so I don't think it is worth detecting this special case (especially as it is maybe not so easy, we lack that context inside EventDispatcher).. As creating a single autoloader is often relatively cheap, the main problem is when it keeps recreating them. The other issue is that we do not actually load the project's autoloader, so this would fail if we do not create an autoloader inside run-script. |
f983c75 to
8ead554
Compare
Only create autoloaders when needed, and avoid creating duplicate autoloaders Refs composer#8587
8ead554 to
3372a31
Compare
Only create autoloaders when needed, and avoid creating duplicate autoloaders.
In pathological cases like declaring a post-package-install script as
"Foo::bar", it would classmap-scan the whole project on every package being installed, causing 200ms of delay at every package. Trying this on a repo here this PR improves a fresh install time from 38 down to 9seconds, which is quite dramatic. I suppose other cases where large classmaps or listener-heavy plugins are present might also see significant speedups.Targetting 2.9 though because it does carry some risk of regression in case I missed a corner.
Refs #8587