[05:51:59] 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%) [05:55:29] this was on mostly vanilla MW, but still 500+ interfaces does seem like a lot [06:40:31] https://github.com/wikimedia/mediawiki/blob/master/includes/HookContainer/HookRunner.php#L29-L571 huh [06:50:33] core hooks are split between an ApiHookRunner for API hooks and a HookRunner for everything else [06:52:23] is there anything to gain by breaking up HookRunner into new groupings? [06:58:40] 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 [11:17:49] I think part of the rationale for the whole project was that we don't care about non-opcache installs [11:18:07] if it's slow with opcache enabled then that is a concern [11:19:11] there's things we could do to optimise HookRunner but it would be fairly ugly [15:51:52] <_joe_> I think at this point we should assume anyone vaguely interested in performance should have opcache turned on [17:00:17] heh [17:00:23] "think of the shared hosting!" [17:20:57] pretty sure all of them have opcache turned on too [17:21:13] and if they don't, they should find better shared hosting :P [17:22:25] I have opcache disabled on my dev/test install, but that's more because opcache + xdebug don't play nicely together (some stuff may be optimized out so xdebug can't view it) [17:22:52] but that being slower isn't really relevant as long as stuff doesn't time out