gerritbot added a comment.
Change #1035864 **merged** by jenkins-bot:
[pywikibot/core@master] Revert "[IMPR] use CachedRequest for userinfo
requests"
https://gerrit.wikimedia.org/r/1035864
TASK DETAIL
https://phabricator.wikimedia.org/T348925
EMAIL PREFERENCES
gerritbot added a comment.
Change #1035864 had a related patch set uploaded (by Xqt; author: Xqt):
[pywikibot/core@master] Revert "[IMPR] use CachedRequest for userinfo
requests"
https://gerrit.wikimedia.org/r/1035864
TASK DETAIL
https://phabricator.wikimedia.org/T348925
EMAIL
gerritbot added a comment.
Change #1034059 **merged** by jenkins-bot:
[pywikibot/core@master] [IMPR] use CachedRequest for userinfo requests
https://gerrit.wikimedia.org/r/1034059
TASK DETAIL
https://phabricator.wikimedia.org/T348925
EMAIL PREFERENCES
Xqt added a comment.
The regression was introduced with Pywikibot 8.1 (see above). Previous runs
were 30 times faster for the first time and 300 times for the second. The patch
above fastens up the second call but the api calls seems sequentiell instead of
simultaneously which would be
gerritbot added a comment.
Change #1034059 had a related patch set uploaded (by Xqt; author: Xqt):
[pywikibot/core@master] [IMPR] use CachedRequest for userinfo requests
https://gerrit.wikimedia.org/r/1034059
TASK DETAIL
https://phabricator.wikimedia.org/T348925
EMAIL PREFERENCES
Xqt added a comment.
Hi @ericpien: I think `preload_sites` script is a good measurement. After
collecting the `siteinfo` (and after Pywikibot 8.1 `userinfo`) the second call
must much more faster. Thank you for your patch but I would suggest to use the
already implemented CachedRequest
ericpien added a comment.
Hi @Xqt what tests would you recommend to ensure the change is not causing
regression?
I have the code change:
https://gerrit.wikimedia.org/r/c/pywikibot/core/+/1033715 where userinfo is
being cached and read based on family name and username matches.
