"Make action=credits faster" is not a valid bug report, as it's unfixable (when is it "fast enough")?

Needs some actual criteria to become a bug report...

(In reply to comment #1)

Needs some actual criteria to become a bug report...

They'll need to be added by someone who knows the requirement for enabling it on WMF wikis.

mysql:wikiadmin@db1056 [enwiki]> EXPLAIN SELECT /* WikiPage::getContributors 192.168.0.18 */ rev_user AS user_id,rev_user_text AS user_name,user_real_name,MAX(rev_timestamp) AS timestamp FROM revision LEFT JOIN user ON ((rev_user = user_id)) WHERE rev_page = '1' AND (rev_user_text != '192.168.0.18') AND ((rev_deleted & 4) = 0) GROUP BY rev_user,rev_user_text ORDER BY timestamp DESC\G

• 1. row ******* id: 1 select_type: SIMPLE table: revision type: ref

possible_keys: PRIMARY,page_timestamp,usertext_timestamp

    key: PRIMARY
key_len: 4
    ref: const
   rows: 1
  Extra: Using where; Using temporary; Using filesort

• 2. row ******* id: 1 select_type: SIMPLE table: user type: eq_ref

possible_keys: PRIMARY

    key: PRIMARY
key_len: 4
    ref: enwiki.revision.rev_user
   rows: 1
  Extra:

2 rows in set (0.03 sec)

Main problem:
Extra: Using where; Using temporary; Using filesort

(In reply to comment #1)

as it's unfixable

Um, [Citation Needed]?

@sam Reed

IMO, this looks to be pretty complicated to achieve to build an efficient solution without computing this list asynchronously (and storing it somewhere).

In T49721#2140494, @Addshore wrote:

So taking a quick look at this it looks like the expensive bit here is the getContributors method in CreditsAction which calls WikiPage::getContributors which will hit the db every time.

In theory this should be easy to cache in some way