@aaron @Krinkle is this something Performance-Team plans to work on? Seems like a good idea, but Growth-Team doesn't have bandwidth to do it in the short-to-medium term.

I guess it can go on our backlog.

OK, thanks for letting us know.

In miser mode, recent changes and watchlist do not display the edit count (Linker::buildRollbackLink). But the views call Linker::generateRollback, which calls Linker::getRollbackEditCount regardless. So the edit count is always computed, it isn't just displayed. This is probably a bug.

In T122546#9035971, @matej_suchanek wrote:

In miser mode, recent changes and watchlist do not display the edit count (Linker::buildRollbackLink). But the views call Linker::generateRollback, which calls Linker::getRollbackEditCount regardless. So the edit count is always computed, it isn't just displayed. This is probably a bug.

That was changed in https://gerrit.wikimedia.org/r/c/mediawiki/core/+/867732, after on ChangesList (that is for watchlist/rc) and ContribsPager there was no verifiy parameter to Linker::generateRollback and that results in always getting the count. (with mitigation for performance in https://gerrit.wikimedia.org/r/c/mediawiki/core/+/870738, the verify was removed later in https://gerrit.wikimedia.org/r/c/mediawiki/core/+/871018). So this has a visible impact on wiki for rollback users, as there are no more useless rollback links on Special:Watchlist/RecentChanges or Special:Contributions.

Currently my Wikidata watchlist is loading fairly slowly (~8-13s backend response time) and it's spending a lot of time (~25%) for these queries (in Linker::getRollbackEditCount). I've captured such a request in xhgui.

As getRollbackEditCount also checks the revision deletion status of the last edit by another user, page_touched should probably also be part of the caching key (revision deletion seems to update page touched).

While this proposal seems straightforward to implement, I have some doubts.

• There are usually few users with rollback rights on wiki, compared to the community size. So, the cache is useful only to a few users.
• Except for contribution pages of recently active users (to be patrolled), it's unlikely those few users would check contributions of the same set of users (if any).
• There could be as many keys as pages on the wiki, and they could be generated at a very high rate by simply browsing users' contributions to the past. So, there is a risk of flooding the cache with never-again-used keys that expire in stampedes.

Cross-linking: T378764#10282718.