On 11/13/07, Stephen Bain stephen.bain@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@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.