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