--- Comment #2 from Rob Lanphier <> 2010-09-25 04:51:33 UTC 
For option 1, we'd want to store probably more recent history than just the
very latest.  We wouldn't need to store everything, but the tough part is that
I don't think we've got a natural way of invalidating the old content, short of
implementing a garbage collector.  

I suppose one alternative to garbage collection would be pick an arbitrary
number of cache slots, and then modulo the revision number.  For example, if we
decided we were only going to store a maximum of the last 5 million revisions
[a little less than a month on enwiki at current rates], and oldid was
4006000123, we would modulo oldid by 5 million and use slot 1000123 as the
place to store the cached version.  Then when we went to cache 4011000123, we
would put it in 1000123, overwriting 4006000123.  I'm guessing even a few hours
worth of history caching would buy us a lot of parser performance benefit.

For option 2, we would probably use Javascript to fetch the old revision, but
we wouldn't make the user click the link.  We'd just automatically request it. 
The benefit would be that the diff and the buttons would render right away, and
then the rest would load in its own sweet time, but the reader would probably
be distracted reading the diff long enough to load the old revision most of the
time anyway.

Configure bugmail:
------- You are receiving this mail because: -------
You are on the CC list for the bug.

Wikibugs-l mailing list

Reply via email to