[15:54:42] php seems to be starting an RfC on finally making ext/dom support html5: https://wiki.php.net/rfc/domdocument_html5_parser [16:00:36] "The biggest threat to the economic value of code is that everything is always in flux." — Baldur Bjarnason https://blog.jim-nielsen.com/2023/software-crisis-dependencies/ [16:00:49] Reminds me of Tim-away 's 2018 position statement https://www.mediawiki.org/wiki/Wikimedia_Developer_Summit/2018/Participants#Tim_Starling [16:00:58] I decided to reference both in https://timotijhof.net/posts/2023/an-internet-of-php/ [22:38:01] about a quarter of all settings in InitialiseSettings.php only specify a value for 'default' -- i.e., only one value for all wikis. Can those be turned into simple globals in CommonSettings.php? [23:11:56] ori: possibly. It think we've been moving somewhat intentionally in the opposite direction though. Not for very strong reasons but lacking incentive against its been moving. Roughly: 1) reducing code-as-code and adding a barrier to writing logic in that file, 2) vague future of loading config as static array directly in MW core without global vars, 3) more recently a desire to split IS.php into core- and ext- files to be more accessible [23:11:56] to new devs and create sense of ownership. [23:16:08] I removed the disk cache of wgConf->getAll from wmf config, as loading a big json file and parsing it became on-par with php iterating through IS.php and plucking out what it needed. The main cost that was remaining was the loading of db lists which happened implicitly as part of a cache miss so I turned those into a php array file [23:16:29] ori: I assume your angle is perf right? [23:17:06] https://phabricator.wikimedia.org/T169821 [23:17:15] ref T169821 [23:17:16] T169821: Try to make wmf-config/wgConf's per-wiki configuration cache redundant - https://phabricator.wikimedia.org/T169821 [23:35:22] this reminds me, I've been thinking, maybe what we need is not O(1) apuc_fetch(), maybe we just need a serialization format optimised for unserialize speed [23:35:52] like pointer-swizzled native arrays [23:36:50] the costly thing is calling the allocator a million times -- if you can just set up all your structures inside the input string, that should be much faster [23:40:38] you then need to control destruction timing, but that can be done by setting the refcount sufficiently high and having the blocks tracked by an extension global [23:49:56] > apc_fetch returns copy of cached values. https://github.com/krakjoe/apcu/issues/175 [23:50:08] HHVM's blissful image of a world with infinite memory did have its benefits [23:51:00] maybe that new immutable_cache extension is worth looking at [23:51:18] it's basically apcu without GC, so you take responsibility [23:51:46] shoudl work nicely for things like this and for ExtensionRegistry as well where we can assume just one key will be set. [23:51:52] per php-fpm lifetime [23:52:42] in theory that woudl be like writing an array file to opcache, except without the disk and php eval nastiness. no idea if its actually that optimal or not.