[15:42:40] Krinkle: Not sure if the 'improvements' in switching fresnel over are real; if PHP 7.4 is really 20% better at TTFB that'd be brilliant, of course. [15:43:23] James_F: we definitely saw an overall latency improvement, but not sure how observable that is on tiny mw stock Main Page views [15:43:39] Benchmarks about PHP 7.4 from SRE for pageviews and ResourceLoader: https://phabricator.wikimedia.org/T311386#8052799, from Parsoid team: https://phabricator.wikimedia.org/T312638#8134510 . [15:43:47] Ack. [15:44:55] It's a bit of a pain that the PHP 7.4 and the CPU performance change are going out so close to each other, as distinguishing the impact may be a challenge, but it's great if we can ship more pages faster with fewer machines. [15:45:44] I wonder if the 7.4->8.0 migration will also be impactful in terms of performance; if so, we may wish to schedule that sooner than later. [15:51:54] James_F: Yep, our thoughts exactly. From upstream about PHP 8: https://www.php.net/releases/8.0/en.php#consistent-type-errors-for-internal-functions and https://www.php.net/releases/8.1/en.php#performance_improvements [15:52:21] upstream already highlighted MediaWiki in the php 8.0 release notes [15:52:32] bit of a shame we're not running it, clearly they managed to :P [15:55:10] Ha. [15:55:39] I have hope that I'll kill the 7.2 support in CI next month, and then we'll be able to move some libraries and thus start running 8.0 support in CI instead. [15:55:58] But that depends on the production roll-out of PHP 7.4 of course. :-) [16:31:12] There's active progress on it again though [16:31:14] Which is obviously good [16:31:24] And one big blocker (ES) is out of the way [17:55:28] Ah, ElasticSearch. So I gather the dependency mess for resolved / obsoleted by dropping 72? [17:59:29] Both the frequency governor change and the PHP 7.4 migration optimize the same bottleneck (CPU), so it's reasonable to expect smaller effect from PHP 7.4 [18:41:23] Krinkle: They finally upgraded to a version that supports both 7.2 and 8+ [19:50:52] PHP 8.1 should be even a bigger perf improvement than PHP 8.0. Their symfony benchmark improved by 23%. [20:45:38] That's a bit surprising, I'd have expected the introduction of JIT to play a bigger role [20:46:03] I do remember getting some great results on running the Parsoid test suite on PHP 8 a few years back, but sadly the numbers are lost to IRC [21:03:18] mszabo: I think most of that 23% is the JIT getting better in version 1 after the version 0 introduction [21:04:38] Fair point [21:05:07] Someone did note that their globals changes may require adjustments in MediaWiki because accessing $GLOBALS entries is now linear time rather than constant time [21:05:18] so GlobalVarConfig will likely need to account for that [21:05:49] https://github.com/php/php-src/issues/9429 [21:46:55] mszabo: nice catch. Is the author a contributor? [22:53:35] Ugh. The optimization of using isset() for that check of $GLOBALS wouldn't be semantically right for the usage because of the handling of nulls and GlobalVarConfig::get() throwing when GlobalVarConfig::has() is falsey. [22:54:16] calling GlobalVarConfig::get("somethingInitializedAsNull") would start throwing [22:57:24] bd808: ack. but we could probably do both, on the assumption that we only need to check has_key if and only if isset() returns false. [22:57:32] it's okay if the throw-case is less optimal [22:57:57] as it shouldn't happen in prod [22:58:03] the exists-with-null case is prod-able, but not sure how common [22:58:50] *nod* belt and suspenders checks should work. And I would expect that both the null value and missing value cases are much lower frequency in actual usage than hits [22:59:14] but maybe by the way we worry about 8.1, upstream will have patched 8.1 to Just Work