With buster, file loading/stat-ing syscalls are slower, so AutoLoader is where a lot of regression is showing up (see detailed explanation in T273312).
We should look into the impact caused by HookRunner loading 500+ interfaces and if there are any straightforward ways to migitate/reduce that (e.g. putting all the interfaces in one/two files)
Notes from IRC:
21:51:59 <legoktm> I started looking into autoloader perf, and it seems like most of the classes we're loading in a simple load.php request are just the hook interfaces: https://phabricator.wikimedia.org/P14211 (74%) 21:55:29 <legoktm> this was on mostly vanilla MW, but still 500+ interfaces does seem like a lot 22:40:31 <ori> https://github.com/wikimedia/mediawiki/blob/master/includes/HookContainer/HookRunner.php#L29-L571 huh 22:50:33 <ori> core hooks are split between an ApiHookRunner for API hooks and a HookRunner for everything else 22:52:23 <ori> is there anything to gain by breaking up HookRunner into new groupings? 22:58:40 <legoktm> ori: maybe, I was thinking of a "SetupHookRunner" for early stuff like the hook in MediaWikiServices, SetupAfterCache, WebRequest::getIP, but stopped looking after seeing it go into LanguageFactory/Language 00:00:00 - {Day changed to Friday, February 5, 2021} 03:17:49 <TimStarling> I think part of the rationale for the whole project was that we don't care about non-opcache installs 03:18:07 <TimStarling> if it's slow with opcache enabled then that is a concern 03:19:11 <TimStarling> there's things we could do to optimise HookRunner but it would be fairly ugly