[03:51:43] AaronSchulz: RE https://gerrit.wikimedia.org/r/c/mediawiki/core/+/636465 - PET don't use Gerrit notifs or dashboards. prolly tag a task? [08:29:03] https://auth0.com/blog/whats-new-php-8/ [16:20:58] I do wonder if we'll be seeing any noticeable improvements for JIT while parsing crazy wikitext [17:48:20] If parsoid weren't "close", I'd have asked upstream to specifically take a look at profiling benching that as a test case [17:48:35] Might still be worth doing, for Parsoid that is [17:49:15] Hhvm had a MW install as test case in their foss benches among Wordpress etc [21:13:01] close as in close to being moved into core? [21:18:53] quick nonauthoritative benchmark: running parserTests.php on an i7-8559U macbook [21:18:55] php 7.3 - 19.91s user 0.57s system 92% cpu 22.082 total [21:19:02] php 8 - 4.09s user 0.45s system 79% cpu 5.689 total [22:50:26] mszabo: close as in, becoming relevant to Wikipedia page views and thus more impactful/representative [22:50:40] it has been ported to PHP, and is already bundled as composer lib in core [22:50:47] however not yet used for anything by default [22:51:15] RESTBase in WMF prod calls into it via rest.php for mobile apps and VE. [22:51:26] same as previously more or less [22:51:55] mszabo: nice stats [22:53:03] it might not make much sense to now invest in legacy parser being included in high-level benchmarks as it is a long term investment for visibility which might not pay off much since in a few years it'll hopefully not be used much if at all during regular page views for stock installs incl at WMF. [22:53:17] I'd rather e.g. opcache become optimised for how parsoid works [23:12:29] parsoid main parserTests take ~80s as opposed to ~450+ s with php 8 [23:12:43] mszabo: Woah. [23:12:44] that's without -d opcache_cli=1 [23:12:48] mszabo: Do they also pass? :-) [23:12:51] they do [23:12:54] Gosh. [23:12:58] but with -d opcache_cli=1 they crash :P [23:13:03] Ha. [23:13:06] Unsurprisingly. [23:13:09] "PHP Fatal error: Uncaught TypeError: Wikimedia\Parsoid\Utils\Utils::isValidDSR(): Argument #1 ($dsr) must be of type ?Wikimedia\Parsoid\Core\DomSourceRange, Wikimedia\Parsoid\Core\DomSourceRange given" [23:13:13] sounds like a php bug [23:13:13] PHP opcache considered harmful. [23:13:26] Err. [23:13:33] That definitely sounds like a PHP bug, yes. [23:13:41] Unless that's a new language contract? [23:14:55] I think it's either a bug or there's a real type mismatch but the reporting is all off [23:15:05] Right. [23:15:05] and it's not there without -d opcache_cli=1 sooo [23:16:26] Sadly sury.org's version is still 8.0.0rc3 so I can't do the CI image stack. [23:16:35] I'm sure it'll be .0 tomorrow. [23:24:43] fingers crossed :) [23:24:56] mszabo: if you can repro that a bit smaller, would be a good one to give to upstream [23:25:09] might be opcache getting confused in a certain edge case [23:25:22] Well, I had a "todo" to make this images months ago, but the published images of PHP 8.0-beta kept failing their own test suite, so my faith wasn't high. [23:25:41] 8.0.0 is stable as of yesterday [23:25:52] there are no more bugs [23:26:34] Sure there aren't. ;-) [23:26:53] But yeah, my testing was in April. [23:29:54] and suddenly I can't reproduce it anymore [23:30:04] Oh dear. [23:30:04] maybe I was imagining it the whole time [23:30:25] Non-deterministic bugs in the opcache are not good. [23:30:39] oh, the problem is with me because -d opcache_cli=1 is not a flag [23:30:44] opcache.enable_cli=1 is a flag [23:32:44] now I can get it again