On Fri, Jul 30, 2010 at 4:13 AM, Domas Mituzas <midom.lists(a)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.