[01:09:57] what is the actual point of startAtomic()? [01:10:34] 99% of the time it is a no-op [01:13:11] the problem is implicit transactions -- with startAtomic(), an implicit transaction caused by a read query creates a hard requirement that there be no COMMIT until the end of the request [01:15:33] how can terminate an implicit transaction apart from waiting until the end? [01:23:08] rubber duck says flushSnapshot() -- if you do flushSnapshot() prior to startAtomic() then you do actually get a real transaction [01:30:17] that's sufficient to get a new transaction to start, but Database.php line 4478 basically says that a web request should never have multiple transactions and that logic causes endAtomic() to not do a commit even if startAtomic() was preceded by flushSnapshot() [03:49:46] context is https://phabricator.wikimedia.org/T287859#7254483 [19:04:21] Pchelolo: Hi, I don't now if it's related to the recent refactors but now a simple rendering of a page calles ParserOptions::getOption 50K times https://performance.wikimedia.org/xhgui/run/symbol?id=610990e8741f6b999e0761ff&symbol=ParserOptions%3A%3AgetOption [19:05:02] Amir1: hm... we haven't really touched ParserOptions recently as far as I can remember [19:05:33] okay, I dig then [19:06:41] seems like it's 20k for getMaxPPNodeCount and 20k for getMaxPPExpandDepth [19:07:18] yeah, found the root cause [19:07:25] it's a simple fi [19:07:28] *fix [19:07:28] mmm, me is curious [19:07:44] PPPFRame_Hash::expand() [19:22:43] Pchelolo: I feel this would help https://gerrit.wikimedia.org/r/c/mediawiki/core/+/709812