https://bugzilla.wikimedia.org/show_bug.cgi?id=25289
--- Comment #2 from Rob Lanphier <ro...@wikimedia.org> 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: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. _______________________________________________ Wikibugs-l mailing list Wikibugs-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikibugs-l
