[11:44:04] James_F: I don't think it has to do anything with B/C, we could easily introduce a forced caching mode. The fundamental difference is that REST API handlers are in full control of their endpoint and Action API modules aren't. (Even for non-query modules, there's another module handling formatting, a third one handling error formatting, the main module has its own parameters...) [11:47:27] Krinkle: ApiOpenSearch responds with Cache-Control: private, Vary: Cookies if you are logged in. [11:47:38] Takes me about 400ms right now. [13:06:42] I was looking at some flamegraphs and noticed CategoryTree::createCountString taking up 2+% of processing time, mostly due to repeated message invocations [13:07:06] on the surface this is a similar problem to T341319, and so it got me wondering if it might be useful to introduce an LRU process cache for message outputs to handle these in a more general way [13:07:07] T341319: RecentChanges: Improve performance of Special:RecentChanges rendering - https://phabricator.wikimedia.org/T341319 [13:08:31] https://usercontent.irccloud-cdn.com/file/LyxPQ7OX/Screenshot%202024-04-11%20at%2015.07.55.png [13:09:49] in theory, the cache could vary on the key, the parameters and the lang code as well as the title (if any) and the IF message flag [19:46:27] tgr: Yeah, from my reading it was tried to made `uselang=content` be the default, instead of `uselang=user`, but it (understandably) broke a bunch of things and so was reverted and codified. Having made a REST end-point equivalent last-night it's much simpler and more extensible for this use case, you're right. Thanks! [20:25:39] James_F: yeah, that probably can't be changed, as unfortunate as it is for a default (because most developers don't realize that API calls will be uncacheable by default). We could probably make mw.api add uselang by default, instead. [20:27:19] But letting API modules mark themselves as language-independent and have that affect caching somehow is a different thing, and that's totally doable. It would just interact weirdly with non-language-independent things in the main module etc. [20:29:28] I think in practice that means errors and warnings. Some of which can originate outside the module, e.g. assert= or paramater usage warnings. [20:30:42] Not completely unacceptable as a tradeoff, but just making sure to always set uselang seems simpler, if it's just about a single API module. [20:31:19] In a more general sense, the action API isn't very caching-friendly anyway, because it's URLs are just too variable. [20:31:59] If you would also need cache invalidation, it's basically impossible. [20:33:31] If you don't - e.g. MediaViewer uses uselang + smaxage, AFAIK that works fine.