https://bugzilla.wikimedia.org/show_bug.cgi?id=55192

--- Comment #2 from Kunal Mehta (Legoktm) legoktm.wikipedia@gmail.com --- - **assigned_to**: russblau --> nobody - **summary**: Multiple user info request --> Rewrite Performance (multiple API request)

https://bugzilla.wikimedia.org/show_bug.cgi?id=55192

Amir Ladsgroup ladsgroup@gmail.com changed:

What |Removed |Added ---------------------------------------------------------------------------- Priority|Unprioritized |High CC| |ladsgroup@gmail.com Version|unspecified |core (2.0)

https://bugzilla.wikimedia.org/show_bug.cgi?id=55192

John Mark Vandenberg jayvdb@gmail.com changed:

What |Removed |Added ---------------------------------------------------------------------------- Blocks|70936 |72118 Summary|Rewrite Performance |Repeatitive API userinfo |(multiple API request) |queries

--- Comment #3 from John Mark Vandenberg jayvdb@gmail.com --- Im not sure how the code looked before about April 2014 .. so my comment are unrelated to how the code looked when this bug was raised in 2012.

Since at least 2014, userinfo is added to every query, and the response is used to determine whether the server has a different username than pywikibot expects. This occurs in usual usage for two reasons:

1. the bot starts logged out, but with the cookies sent, the server may reply with a username, in which case the server considers the bot logged in. So pywikibot changes the login status of the APISite accordingly.

2. the server invalidates the bot's session, or maybe even credentials e.g. when we had a forced password reset.

So there are many API requests and responses with a small chunk of extra data. This could be removed/reduced, with a lot of pain, and little gain.

There are also many times where the code base sends the exact same userinfo+siteinfo request several times, because the login code is a mess. However, these are cached locally on disk - which is still a performance problem as this requires disk IO for a tiny chunk of data that the code has already parsed and discarded.

I fixed a few of these reload scenarios back in July/August, but it is not fun fiddling with the login/relogin sequence.

IMO we should wait until we've released a stable version of 2.0, and then redesign the user/login system, removing the two user system that is heavily embedded in the current codebase. That will probably require a breaking change for sysop-bots, but bot-bots should be unaffected.