Steps to replicate the issue:
- Install MediaWiki master (e.g. current master 1.39.0-alpha) with basic configuration (no extension, one skin),
- Activate $wgDebugToolbar = true; and $wgDebugDumpSql = true;
- Open the Main page and check the SQL requests:
1/ First as unlogged user:
There is a SQL request
SELECT user_name,up_value FROM user LEFT JOIN user_properties ON ((user_id = up_user) AND up_property = 'gender') WHERE user_name = '127.0.0.1'
⇒ This request could be avoided since the gender of an anonymous user is always the default value (and if I’m not mistaken, it is also the case for temporary users).
2/ Second as logged-in user:
There is a SQL request
SELECT user_name,up_value FROM user LEFT JOIN user_properties ON ((user_id = up_user) AND up_property = 'gender') WHERE user_name = 'MyUsername'
But this request comes after a previous one more general
SELECT up_property,up_value FROM user_properties WHERE up_user = 1
⇒ The result is already known and accessible through the UserOptionsLookup service, and in this case the SQL request could be avoided.
What should have happened instead?:
In the case GenderCache only searches the gender of the current user (which always occur to create a link to their userpage, in the skin subsystem), this SQL request could be avoided.
I agree the marginal time is useless if GenderCache does a request for multiple users, but there are a lot of pages where there is no links to userpages (of other users), so I guess the case is quite common.
I have no idea how much performance gain we can gain, but I think it is always beneficial to reduce the number of SQL requests for already-requested and easy-to-obtain informations.