Search for updates (xbps) became laggy a few months ago.

[gc-user]

Since a few months now I had the impression that the time between downloading the latest repo data and displaying the list of avallabe updates has significantly increased.

The other day, there was a xbps update, so I took that as an opportunity to test a few snapshots to see if my impression was correct and if so, when the "lagginess" started.

It seems that sometime between end of December and middle of March that "lagginess" started.

With a BE from December it takes ~3s from hitting enter to the list of available updates being displayed.
With a BE from March it takes ~8s for the same.

Of course, xbps would be the first package to suspect for being the cause, but those two snapshots use the same version of xbps. So that can't be it.

Updating xbps (and libxbps) brought along two other updates, glibc and xtools-minimal.

After performing that update the "lagginess" started.

Removing a bunch of packages to be able (due to dependencies) to update glibc and xtools-minimal, respectively, on their own (of course on a fresh BE from the December snapshot each time) I thought I had found the culprit, because updating xtools-minimal introduced the "lagginess" - but downgrading that package again doesn't bring back the "snappiness".

So, I can't blame it on a specific package or combination of specific packages. But at least I could see that there is in fact a "lagginess" in the process of displaying the list of "updatable" packages compared to a few months back.

This "lagginess", btw.., also affects octoxbps-notifier (which is probably unsurprising as it just a gui for xbps, searching for updates in the background). It now takes way longer for it to change the indicator from red to green when updates are completed. In the past that was essentially instantly after the last update was completed, now it's ~10-12s after that.

Btw., the tested BEs all have the same dns settings, all contact the same repo server, and checking for updates when there are none (no list of available updates has to be produced / displayed) is "snappy" as always, no matter if it is laggy or not when there are updates available (i.e. if it uses the "old" or the "new" versions of the packages mentioned above).

There seems to be some change in the process that calculates from the downloaded repo data and the installed packages the available updates - or in the process that displays / reports that output. As xbps(-install) itself doesn't seem to be the problem there must be some other reason / interference to cause this issue.

xdowngrade also seems to have a longer "pause" between the part where the files are reported to having been added to the index and showing the list of the packages to downgrade and asking whether to proceed or not.

[Duncaen]

xbps-src started to a add a lot of virtual packages (for pkgconfig files and commands in /usr/lib (xbps-query -p provides --regex -s '^(cmd|pc):')), and xbps scale well with many virtual packages because it does a linear search over the list of virtual packages instead of something faster like using a hashmap. void-linux/xbps#625

[gc-user]

Thanks for the super-fast reply and explanation!
Good to hear this is fixable and in the works!