Winget List command takes 10 seconds to complete.

[ghost]

Steps to reproduce

winget list literally takes more or less than 10 seconds to print installed apps list.

Expected behavior

as a command line application, retrieving installed apps list should be instant.

Environment

[denelon]

@ecovio1 thanks for reporting this. It may be related to what we have to do to get the list of Apps from "Add/Remove Programs" and match them with the list of matching packages in the sources you have configured. Some work was done to speed this up, but there may still be more we can do.

[Elias-Graf]

winget list actually takes even longer than 10s for me, roughly 24.

~\git> Measure-Command { winget list }

Days              : 0
Hours             : 0
Minutes           : 0
Seconds           : 24
Milliseconds      : 427
Ticks             : 244277791
TotalDays         : 0,000282728924768519
TotalHours        : 0,00678549419444444
TotalMinutes      : 0,407129651666667
TotalSeconds      : 24,4277791
TotalMilliseconds : 24427,7791

After that, it weirdly lists (what looks like) every program on my system, not just those installed with winget. I don't know if that's the desired result nor do I particularly mind it, especially if I can use it to uninstall everything on my system, but it would definitely be nice if it is somehow cached that result.

The output that the author posted, in case it is of any use:

~\git> winget features
The following experimental features are in progress.
They can be configured through the settings file 'winget settings'.

Feature                 Status   Property            Link
-----------------------------------------------------------------------------------
Microsoft Store Support Disabled experimentalMSStore https://aka.ms/winget-settings
Packaged API Support    Enabled  packagedAPI         https://aka.ms/winget-settings
~\git> winget --version
v1.0.11694
~\git> winget --info
Windows Package Manager v1.0.11694
Copyright (c) Microsoft Corporation. All rights reserved.

Windows: Windows.Desktop v10.0.22000.168
Package: Microsoft.DesktopAppInstaller v1.15.11694.0

Logs: %LOCALAPPDATA%\Packages\Microsoft.DesktopAppInstaller_8wekyb3d8bbwe\LocalState\DiagOutputDir

Links
--------------------------------------------------------
Privacy Statement   https://aka.ms/winget-privacy
Licence Agreement   https://aka.ms/winget-license
Third Party Notices https://aka.ms/winget-3rdPartyNotice
Homepage            https://aka.ms/winget

Also for completeness sake: I'm using windows 11

[JohnMcPMS]

@Elias-Graf , list is intended to show everything on the system (and uninstall is intended to allow you to interact with everything as well).

That is impressively long; I was thinking we should have caching when I was measuring ~600ms to resolve the localized names of the MSIX packages on the system. If you could provide a log file from the long running list command, I could start to look into exactly what is taking so long.

If you run winget list --verbose-logs then get the latest file from %LOCALAPPDATA%\Packages\Microsoft.DesktopAppInstaller_8wekyb3d8bbwe\LocalState\DiagOutputDir it should hopefully point to where the time is being spent.

If you prefer, you can run winget list --verbose-logs then use Feedback Hub via http://aka.ms/winget-feedback and report the feedback id here.

[Masamune3210]

I have a lot of stuff installed and this install has been through all of 10 up to now, so it may just be something causing a issue but 791ms for a list seems egregious

[Masamune3210]

Apparently newstore was causing a lot of the issue, after disabling and removing it it drops down to 394 for me

[Elias-Graf]

@JohnMcPMS Well, some time elapsed and of course my system changed. E.g. restarted the computer, installed further windows 11 beta updates. And it looks like that resulted in the winget list command consistently taking roughly 1.5s. That is way more pleasant, if not acceptable. Although it has to be said that at the time of writing this comment I'm facing #1437.

If it gets worse I will get back to you, and if you still want the debug output please get back to me 😊.

[pcbeard]

Using winget source remove newstore is a good workaround for #1437, and it seems to have sped up winget list.

[JohnMcPMS]

This should be fixed by our more recent pre-release packages, assuming that the vast majority of extreme times was due to the msstore source. In particular, v1.0.12576 is the first to have the fix.

Generally we do need to improve the behavior in this area long term, likely via a caching mechanism of some kind. Alternately (really, in addition to) we could remove the upgrade availability indicators from list to improve performance. Now that we have upgrade it might make sense to do so, but probably not before the caching is in place due to the implementation details.

[ghost]

@ghost this issue has been automatically marked as stale because it has been marked as requiring author feedback but has not had any activity for 7 days. It will be closed if no further activity occurs within 7 days of this comment.

[ghost]

@ghost this issue has been automatically marked as stale because it has been marked as requiring author feedback but has not had any activity for 7 days. It will be closed if no further activity occurs within 7 days of this comment.

[ghost]

@msftbot this issue shall not be closed. It's EXACTLY SAME now in October as it was in April >_<

[denelon]

What version of the client are you currently running on? Can you share the output from winget --info?

Which sources do you have configured?

[denelon]

Some improvements have been made in this area for the 1.3 release. There may still be improvements that need to be made in the future if users are encountering this performance issue.

Let me know if this is still happening.

[ghost]

@ghost this issue has been automatically marked as stale because it has been marked as requiring author feedback but has not had any activity for 7 days. It will be closed if no further activity occurs within 7 days of this comment.

[vedantmgoyal9]

@denelon The user who has posted the issue has deleted the account. This can be closed for now, and if there will be any issue, there is always an option to create a new issue.

[denelon]

@vedantmgoyal2009 we have some ideas on what is causing the performance problem in some cases. We're going to keep this open until we've had a chance to improve the performance (at least in that specific case).

[ghost]

@ghost this issue has been automatically marked as stale because it has been marked as requiring author feedback but has not had any activity for 7 days. It will be closed if no further activity occurs within 7 days of this comment.

[ghost]

@ghost this issue has been automatically marked as stale because it has been marked as requiring author feedback but has not had any activity for 7 days. It will be closed if no further activity occurs within 7 days of this comment.

[Karl-WE]

If winget relies on cim / wmi it is quite naturally slow based on CPU type and number of apps.

If you run a query via PowerShell it should be the same.

[denelon]

The issue related to correlation attempts to the "msstore" REST source has been addressed.

[arcyc]

10 seconds? Lucky! I'm up to 300 seconds on my machine with 400Mbs internet. Pretty sure it's throttling requests on the back end source calls, which is silly since it's a command you run locally to get a list of installed apps on your system, and the backend call are purely incidental. I should be able to run winget list and winget upgrade --all as often as I want locally without throttling on the backend. If the CDN isn't throttling, then there is something seriously wrong with the performance of the backend services.