[04:10:12] mszabo: https://performance.wikimedia.org/excimer/profile/81ec3b90d675bced based on profiling https://www.mediawiki.org/w/index.php?action=history&title=Developers/Maintainers [04:15:44] ref T341319 [04:15:45] T341319: RecentChanges: Improve performance of Special:RecentChanges rendering - https://phabricator.wikimedia.org/T341319 [04:16:10] Let's see if Matej is interested :) [04:17:26] Maybe we need to go crazy and dig a step further and just process-cache MessageCache::parse for simple no-parameter stuff. [04:17:49] that'd also address the N-parse from the Thanks hook visible in the profile here [05:22:26] GenderCache is taking up a big chunk in unbatched queries as well [05:23:38] Looks like HistoryPage/LinkBatch actually try to prime GenderCache, and even anticipates use of both revision user page and editor user page. But LinkBatch::doGenderQuery() is discarding it as !contentLanguage->needsGenderDistinction whereas Thanks needs it for something other than User page URL formatting. [05:23:54] I guess could do with doBatchLookups onPageHistoryPager__doBatchLookups [05:24:32] Although a bit unfortunate that that hooks runs before instead of after, so it means on wikis where content lang does use gender, it'd be two batches instead of one since the Thanks one would run first. [05:25:13] I guess it could try to re-create core's bach and return false but that feels wrong and doesn't scale. [05:25:52] only 1 extension uses the hook (Wikibase) and it doesnt' abort. I wonder why that was implemented this way. [09:25:42] Krinkle: good catch!