winget-cli
winget-cli copied to clipboard
microsoft
Winget List command takes 10 seconds to complete.
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
@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.
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
@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.
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
Apparently newstore was causing a lot of the issue, after disabling and removing it it drops down to 394 for me
@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 https://github.com/microsoft/winget-cli/issues/1437.
If it gets worse I will get back to you, and if you still want the debug output please get back to me 😊.
Using winget source remove newstore is a good workaround for #1437, and it seems to have sped up winget list.
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 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 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.
@msftbot this issue shall not be closed. It's EXACTLY SAME now in October as it was in April >_<
What version of the client are you currently running on? Can you share the output from winget --info?
Which sources do you have configured?
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.
did NOT change anything. 20 seconds even with only winget source.
@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.
@JohnMcPMS Nothing was asked therefore there's nothing to provide Feedback about and therefore "Needs-Author-Feedback" must be lifted. As sated above, still (even in the Latest release to this date) nothing has been fixed regarding this, it's okay if team wants to improve performances side on a later date but the Issue should NOT be closed.
@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.
The issue still persists. Over a minute here for a single command, this is ridiculous 🙄
Can you provide a log file of winget list --verbose-logs. The location of the log files is shown with winget --info. You can also get the logs to us by running the list command, then file feedback in Feedback Hub via https://aka.ms/winget-feedback
I thought that my computer was going crazy because my winget commands are taking about 20-30 seconds to complete. I posted a question here https://github.com/microsoft/winget-cli/discussions/1810
I am happy to known you folks are already on it. There is anything I can do to help?
@JohnMcPMS this is the latest log ....
Winget : 1.2.3411-preview
Windows: Windows.Desktop v10.0.19044.1415
Package: Microsoft.DesktopAppInstaller v1.17.3411.0
WinGet-2022-01-07.log
takes 15 Seconds BTW
@JohnMcPMS This is the latest log ...
Winget : Package Manager (Preview) v1.3.431-preview
Windows : Windows.Desktop v10.0.19044.1503
Package : Microsoft.DesktopAppInstaller v1.18.431.0
👉 WinGet-2022-02-16.log 👉 takes 4 seconds BTW which is still a LOT for a mere "installed apps list".
👉 whereas this following powershell command takes a freaking 295 miliseconds only. not even a full second.
Get-ItemProperty HKLM:\Software\Microsoft\Windows\CurrentVersion\Uninstall\* | Select-Object DisplayName, DisplayVersion, Publisher, InstallDate | Format-Table –AutoSize
I found out that (at least partially) the timing issues have a lot to do with DNS resolution time out (like so often, better look first on DNS…). In my particular case, IPv6 is broken on Windows clients (Apple and Linux devices work just fine, that's a different issue on Windows 10/11, but nothing for WinGet in particular).
Disabling IPv6 on the network interface on Windows immediately improved the situation for WinGet (and others, obviously) A LOT. You may also change the priority from IPv6 first to Prefer IPv4 over IPv6 as described here.
On my Windows machine, this wouldn't have helped as IPv6 connectivity is completely broken for whatever reason. I wasn't able yet to figure out the exact reason, just that after 1 or 2 minutes, IPv6 stops working (no matter if stateless or stateful configuration / SLAAC / DHCPv6… but that's off-topic here!).
Maybe this is something for others with long WinGet runs to look into as well as it really could be about slightly different handling of IPv6 fallback to IPv4 connectivity.
@jpawlowski,
Thanks for the information. We've had a couple of other optimizations in mind, but I don't believe I've heard IPV4 vs. IPV6 potentially being related.
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 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.
@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.
@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 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.