Steven Walling wrote:
On Mon, Jan 30, 2012 at 3:23 PM, Tim Starling
I'm considering introducing a limit on
#switch cases of 2000 or so per
article, to address this issue. No doubt many templates will break,
but it's important to protect our servers, and we've always
discouraged this kind of #switch application.
As a Wikipedian, I would be very happy to see a limitation imposed like
this. I think the silent majority of editors who want to see pages load and
save quickly/reliably outweighs the need for unlimited use of a very
complicated parser functions structure.
This is probably going to read like an attack, but it isn't one.
I continue to view the existence of "expensive parser functions" as a
failure. I don't believe that having users focus on such details is useful
or necessary and I think it largely distracts from any wiki's primary
mission. While these types of functions make a page render/load take longer
(and this unquestionably needs to be addressed), it's more than a vocal and
active minority who favor templates that can do automatic math conversions
and unit labeling, string parsing for automatic page title italics and the
like, and more. In some ways, if these templates weren't so popular, there'd
be no issue. But they're popular for a reason (even if some are only popular
among hardcore template nerds, the result is the same...).
As I recall, it wasn't an overwhelming amount of time that was needed to fix
#ifexist to batch its queries rather than imposing a limit on it (it was
#ifexist that brought the idea of expensive parser functions into existence,
as I remember it... I'm too lazy to hunt down revs). Implementing the latter
was a more interesting coding challenge, I think, and there was a thought
that the methodology used could lay the framework for other parser functions
to be limited going forward (which inevitably happened).
However, I believe this was the wrong approach then and continues to be the
wrong approach now. The time spent here developing ways to limit #switch
rather than fixing the underlying issue (lack of a proper way to do advanced
string manipulation, conversion, etc. in templates) seems like a waste of
time to me, particularly with a better way (Lua) now possibly on the actual
And, for what it's worth, Aaron's comment about the 99% is kind of bullshit.
The 99% aren't editing and are (instead) hitting cache layers. They're
completely unaffected by the slow rendering time. If the 99% were getting
the slow rendering times, this issue would have been solved years ago. It's
because it only hits a subset of users (and a subset of articles) that it's
lingered for as long as it has.