On Fri, Jul 30, 2010 at 4:13 AM, Domas Mituzas midom.lists@gmail.com wrote:
So, we may have 1000x slower performance for our users because they don't really know about our caching internals. Our only hope is that most of them are also ignorant that those settings exist ;-)
There'd be of course another workaround - precaching objects for every variation, at extremely high cost for relatively low impact. Alternative is either having warning icon whenever people are in slow-perf mode that they'd be able to hide, or eliminating the choice (you know, the killing features business, that quite often works really well!!! ;-)
Or we could just store an intermediate form in the parser cache, and apply the settings afterwards. For instance, one preference is "enable section edit links". If instead of outputting HTML, the parser stuck a string like "\001SECTIONEDIT1\001" where the first section edit link goes, we could do preg_replace($page, '/\001SECTIONEDIT(\d+)\001/", $replacement), where $replacement = 'blah blah blah $1 blah blah blah' or '' according to user preference. Then we could use the same parser cache for everyone. I think almost all if not all the parser-changing prefs could be implemented this way, preg_replace_callback() at worst.
So we don't have to remove features, probably. In fact, we can even add features, like {{USERNAME}}. It wouldn't work for {{#ifeq:{{USERNAME}}|Simetrical|You're awesome!|}} or anything, but fine for "Hello, {{USERNAME}}, welcome to Wikipedia!" As long as we keep it down to preg_replace(), or better yet require it to be one big single-pass strtr() for all such settings, it should have no noticeable performance impact even if we add lots and lots of features like this.