Speed Up info_pkgs

[Carterpersall]

Speeds up the retrieval of packages

• Speed up Chocolatey

  • Gets the quantity of folders at $env:ChocolateyInstall\lib, which contains the programs Chocolatey has installed.
  • ~681ms -> 20ms
    • 34x Faster

• Speed up Winget

  • Maybe use the repo's REST API?
    • Doesn't exist yet
  • Reverse engineer?
    • C:\Program Files\WindowsApps\Microsoft.Winget.Source_*.*.*.*_neutral__*\Public\index.db Is the location of Winget's index
      • SQLite database
    • Uses same registry keys used in "system"
      • No idea how they filter data out of the given names in the registry keys, if I figure it out, theoretically this could be done
      • Would require either an absolutely massive lookup table or some fast way to import the SQLite table winget uses
        • Import-Module PSSQLite
          • Invoke-SqliteQuery -DataSource "Location\of\winget\DB" -Query "SELECT * FROM NAMES"
    • https://github.com/microsoft/winget-cli/blob/master/src/AppInstallerCLICore/Commands/ListCommand.cpp
      • List command
      • https://github.com/microsoft/winget-cli/blob/master/src/PowerShell/Microsoft.WinGet.Client/Common/BaseFinderCommand.cs
        • https://github.com/microsoft/winget-cli/blob/master/src/Microsoft.Management.Deployment/PackageManager.idl
          • https://github.com/microsoft/winget-cli/blob/master/src/AppInstallerRepositoryCore/Public/winget/RepositorySource.h
            • Lists all sources of packages
            • https://github.com/microsoft/winget-cli/blob/master/src/AppInstallerRepositoryCore/Microsoft/PredefinedInstalledSourceFactory.cpp
              • Admin: PackageManager.FindProvisionedPackages()
                NonAdmin: PackageManager.FindPackagesForUserWithPackageTypes({}, PackageTypes::Main)
                • Uses WinRT, which is not supported in Powershell 7 without the use of Add-Type code compiling
            • https://github.com/microsoft/winget-cli/blob/master/src/AppInstallerRepositoryCore/Microsoft/ARPHelper.cpp
              • Admin: HKLM
                NonAdmin: HKCU
              • "SOFTWARE\\Microsoft\\Windows\\CurrentVersion\\Uninstall"
  • Maybe use winget export (or cache winget list somewhere as export doesn't work right) and use the "system" implementation and some way to check AppX count to see if program count has changed

• Added "system" to info_pkgs as a faster alternative to "winget"

  • Retrieves the total quantity of 'uninstallable' programs from the registry
    • Very similar to how Winget finds its programs, just without the index
  • Quantity is different from what Winget returns due to the lack of its index, so this couldn't be used as a faster implementation of "winget"
  • Added "system" to default config file
  • Changed the returned string in "winget" to (winget) instead of (system) to clarify that it is Winget and not the entire system

[rashil2000]

Gets the quantity of folders at $env:ChocolateyInstall\lib, which contains the programs Chocolatey has installed.

This method can also be used for info_ps_pkgs (by enumerating over $env:PSModulePath), which currently takes up a lot of time.

[Carterpersall]

Gets the quantity of folders at $env:ChocolateyInstall\lib, which contains the programs Chocolatey has installed.

This method can also be used for info_ps_pkgs (by enumerating over $env:PSModulePath), which currently takes up a lot of time.

Unless we can figure out how to differentiate which packages were installed using PowershellGet, using $env:PSModulePath won't work.
I tried reverse engineering the PackageManagement module, and found that Get-InstalledModule runs PackageManagement\Get-Package @PSBoundParameters | Microsoft.PowerShell.Core\ForEach-Object {New-PSGetItemInfo -SoftwareIdentity $_ -Type 'Module'} where New-PSGetItemInfo is a function that is contained within the same file. I then tried to find the source of Get-Package, which led me to a C# DLL file which I then followed to www.github.com/OneGet/oneget , which then I tracked back to the function GetInstalledPackages() at www.github.com/OneGet/oneget/blob/WIP/src/Microsoft.PackageManagement.CoreProviders/Bootstrap/BootstrapProvider.cs#L241 where I got stuck.
Some time may be able to be saved though by running Get-Package instead of Get-InstalledModule, which causes about a 13% speedup

[rashil2000]

Unless we can figure out how to differentiate which packages were installed using PowershellGet, using $env:PSModulePath won't work.

I mean yes, not all directories of $env:PSModulePath - we need only those that are explicitly installed.

In this, only the top directory has explicitly installed modules. The below 2 are ones that are included in Windows by default, so we don't need to enumerate over them. PowerShell Core can be handled similarly.

I have an implementation ready, will handle it in a separate PR.

[Carterpersall]

I mean yes, not all directories of $env:PSModulePath - we need only those that are explicitly installed.

In this, only the top directory has explicitly installed modules. The below 2 are ones that are included in Windows by default, so we don't need to enumerate over them. PowerShell Core can be handled similarly.

The issue I'm having with this implementation is that the quantity of folders in the directory don't line up with the quantity of modules returned by Get-InstalledModule

Powershell 7:
$env:PSModulePath Method:

• 8 Modules shown

Current Method:

• 6 Modules shown

Powershell 5:
$env:PSModulePath Method:

• 3 Modules shown

Current Method:

• 1 Module shown

Some modules I had installed were also located within the 2 locations that're included by default.

[rashil2000]

Just a heads up: Apps installed by winget will show up as both winget and system. We should prevent double counting.

[Carterpersall]

Just a heads up: Apps installed by winget will show up as both winget and system. We should prevent double counting.

While usually I would agree, I think this could be an exception as this method cannot replace the implementation for Winget because of its lack of an index and UWP apps but is significantly faster than the Winget method.

[Carterpersall]

• I've added caching of Winget's result to the config file
  • Puts the caching script into a PS1 file in $Env:TEMP and runs it in a new PowerShell instance
    • Window is hidden
    • Runs in a new instance so it can continue running even if Winfetch finishes executing
    • Tried to run the script using a scriptblock instead of a file, but for some reason PowerShell was not cooperating
  • While this does mean Winget's package count is always 1 execution behind, the speed gain obtained is worth it in my opinion
  • 2590ms → 46ms
    • 56x Faster