On 11/13/07, Stephen Bain <stephen.bain(a)gmail.com> wrote:
Doesn't this happen anyway? A logged-in user
viewing a page for the
first time will never get a cached version.
Sure they will, if someone with the same parse-affecting preferences
has viewed it before them. And they don't have the "no cached pages"
preference on.
On 11/13/07, Anthony <wikimail(a)inbox.org> wrote:
That's complete nonsense, though. There are
numerous ways to
implement this without having any impact whatsoever on performance.
Maybe the most straightforward solution would impact performance, but
that doesn't mean "it simply cannot be implemented".
No, but what is true is that there is no way to have a magic word that
consistently reflects the current user name, and can be used in
various logical constructs, without invalidating the parser cache on
each view (for re-views not by the same user). Invalidating the
parser cache on each view for a moderately-trafficked page would be,
presumably, a large hit to performance, thus the claim.
Presumably. What's the hit ratio for the parser cache for logged-in
users anyway?
Think about it for half a millisecond. You already
put the username
at the top of the page (next to "my talk"). How is that done? Either
you've figured out how to cache part of the content while keeping
another part dynamic, or you don't cache logged in users anyway.
Most of the use of this suggestion is prevented if the magic word
cannot be used as, e.g., a template parameter. To use it as, e.g., a
template parameter, the page must be re-parsed on every page view. A
parse takes a little under a second for an average page, nowadays.
That's a lot of CPU time when you add it all up. Just inserting the
username in *after* you've already parsed everything would be no big
performance hit, necessarily, just as the username at the upper right
isn't -- but as I say, it wouldn't do everything that the requesters
really wanted. It also wouldn't be consistent with the behavior of
other magic words, which is confusing.
Now, if you wanted to have such a variable so that you could *subst*
it, that's a reasonable request. It would then have the same uses as
{{CURRENTTIME}}, i.e., not perfectly accurate but useful for some
things anyway. I suggested that on the bug, as I recall.