https://bugzilla.wikimedia.org/show_bug.cgi?id=55192 --- Comment #2 from Kunal Mehta (Legoktm) <legoktm.wikipedia(a)gmail.com> --- - **assigned_to**: russblau --> nobody - **summary**: Multiple user info request --> Rewrite Performance (multiple API request) -- You are receiving this mail because: You are the assignee for the bug.

https://bugzilla.wikimedia.org/show_bug.cgi?id=55192 Amir Ladsgroup <ladsgroup(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Priority|Unprioritized |High CC| |ladsgroup(a)gmail.com Version|unspecified |core (2.0) -- You are receiving this mail because: You are the assignee for the bug.

https://bugzilla.wikimedia.org/show_bug.cgi?id=55192 John Mark Vandenberg <jayvdb(a)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(a)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. -- You are receiving this mail because: You are the assignee for the bug.