Powertoys: [pt run] Improve Win32 scanning start up speed

[crutkas]

From issue #6886, a user mentioned they want PT Run to start up instantly. The worst offender is the Win32 app scanning. It took over 80% of the time for start up.

My hope is we'd be able to leverage some parallelism here to improve this.

[crutkas]

As this is a one time hit, that is why i'm pushing this as 'help wanted'

[royvou]

Future improvement would be to async execute the indexing / further improve it as it still takes 2 seconds and is blocking for loading all Plugins.

I think it might be an idea to support async loading of the Plugins(like VS does) /look into ways to further Optimized this, I think the bug/task is still valid.

[alekhyareddy28]

Looks like https://github.com/microsoft/PowerToys/issues/7314 is similar to this issue.

[alekhyareddy28]

Looking at the logs in #7271, the user seems to be facing this issue too. Though the reported issue is different -

From the 2020-10-14.txt log file.

2020-10-14 20:08:22.9256|INFO|Wox.Infrastructure.Stopwatch.Normal|
    Message: |Microsoft.Plugin.Program.Main|Win32Program index cost <67980ms>
    Area: Wox.Infrastructure.Stopwatch.Normal
    Source Path: S:\src\modules\launcher\Wox.Infrastructure\Stopwatch.cs::40

[royvou]

I think I can confirm the issue, the first search is very slow. (3-4 seconds on my machine) Happened about the 0.23 range, but only on the first search..

This PR is related, but I think the issue/cause is different.

[royvou]

@alekhyareddy28 I think the Thread.Sleep at #6821 is a possible culprit, where sometimes the main thread will execute this task? a Task.Delay(5000).ConfigureAwait(false) might help here!

[alekhyareddy28]

I'll modify it to use Task.Delay. However, shouldn't a new thread be scheduled to run this background task?

[alekhyareddy28]

I've been looking into it and using task.Delay would be better than thread.sleep because we're not blocking that thread anymore. However, when we use Task.Run a new thread from the thread pool is assigned that task and that was previously blocked, not the main thread. So even though there might be a performance improvement with using Task.Delay I don't think Thread.Sleep was previously being called on the main thread. Please correct me here if I'm missing something. thanks!

[arjunbalgovind]

Depending on how Thread.Sleep is handled by the OS, if the user has a single core processor (which might be rare nowadays) calling Thread.Sleep on one thread can impact the performance on another thread as the CPU would have to execute them alternately. I'm guessing the OS might be doing some optimization to make sure a sleeping thread is not given CPU time, but it's still a possibility.

[royvou]

Task.Run should indeed run the function on the background thread (with the current synchronisation context) ! And since we are not awaiting it (and configured await) , I would expect it to not block the main thread, a small test with a profiler does mention some main thread work in the constructor though...

I would assume the main thread / another thread is partially locked (for further initialization) until the task is completed?

I'm not sure if async functions in the ctor are handled differently?

It was the most suspecting change though.. (and an improvement anyway)

[alekhyareddy28]

I'm not sure about the thread being blocked till the task is complete. My understanding was that the main thread does not wait for the task to complete unless we use Task.Wait. However, as you said it would be an improvement so I've made the PR.

PT run was previously caching the programs that were indexed but the Win32 cache was removed because it was resulting in some issues such as uninstalled programs showed up, programs installed when PT Run wasn't running were not showing up etc. This increases the boot time from a few seconds to 30 seconds depending on the load on the system.

[royvou]

If i look more close to the PR it should all execute on the background thread yea, but i feel "something" is waiting (async) for it to be completed before it continues. (The main thread is not locked since you can ALT+SPACE and type, it just takes a long time for the results to be available).

Worst part is it won't happen every time (might be related to the indexing it will / won't do / background updates).

All little bits help the performance :)

[alekhyareddy28]

Yes every bit helps! Thanks for pointing it out :)

[royvou]

Last build seems a lot faster, do you have any data yet to suggest how much better it is (on lower end systems)?