Slow launch & UI

[user1823]

Preflight Checklist

• I have searched all open and closed issues for the same feature request without success.

Problem Description

The UI in Everything Toolbar is slightly slow (when compared to other apps).

Proposed Solution

Does Everything Toolbar use Windows App SDK? Asking because it is a known limitation of that framework and an improvement is available in the latest update (1.6).

Native AOT support

Native AOT support

With 1.6, the Windows App SDK now supports native Ahead-Of-Time (AOT) compilation! When publishing your app as a Native AOT app, you produce an app which has been compiled ahead of time to native code for faster startup time and a smaller memory footprint.

We’re very excited to bring the powerful capabilities of Native AOT to developers through the Windows App SDK! In our sample Contoso Camera app, we measured a 50% reduction in start time, an ~8x reduction in package size when using a framework package and a ~2x reduction in package size when using Windows App SDK in self-contained mode. While your results might vary, we encourage you to give Native AOT a try if it’s right for your app!

For more information about Native AOT, see Native AOT deployment. To get started with Native AOT in your Windows App SDK app, see our release notes for 1.6 for what you need to know and how to set it up.

From https://blogs.windows.com/windowsdeveloper/2024/09/04/whats-new-in-windows-app-sdk-1-6/

Alternatives Considered

None

Additional Information

No response

[srwi]

Hi, EverythingToolbar still uses .NET Framework and WPF, so using Windows App SDK is a bit out of the question (but thanks for suggesting!).

I agree that EverythingToolbar can feel slightly sluggish depending on the machine it is running on, but I would be interested to hear from you which parts specifically you notice being slow.

Some things might just be limitations of the tech stack used, while other things could probably be optimized further.

[user1823]

The initial launch is slightly slow.
Also, the list of files is displayed a fraction of a second after I type. It is just a fraction of a second. So, it is not a big deal but it is still noticeable. In contrast, in Everything, the list appears without any noticeable lag after I type.

[pa-0]

At least for me, there is a noticable slowdown between v1.5 and the version immediately preceding it -- for both the initial window to appear as well as any search results to populate the window once search terms have been entered.

[srwi]

How much slower roughly in milliseconds are we talking here? Could you please try downgrading to 1.4.1 again to confirm that it is indeed faster?

I am not sure which changes would affect performance in any noticable way. I would have to take a close look again.

[srwi]

I have played around a little more and noticed these things:

• There is a delay between mouse release when clicking the taskbar button and the window opening. This is caused by the launcher process starting and sending the "open search window" signal to the already running instance of EverythingToolbar. Possibly this time could be optimized. This delay should be constant and independent of whether it's the first time opening the search window or not.
• Toggling the search window using the keyboard shortcut (default should be Win+Alt+S) does not have any delay and feel pretty instant on my machine.
• The closing animation has a lower framerate. This is due to the search window not being focused anymore. WPF will probably assign a lower priority to the animation here. I already looked into that in the past and it's not an easy fix.
• When opening the search window for the first time this will trigger the first search request. Probably this is what you are referring to with slow first launch. Possibly this could be optimized by doing the first search already in the background.
• Updating the search results can cause some flickering as already reported in Search result is flashing when inputing search keyword #89.

Did you observe any other systematic slowdowns?

[Hex34568]

I have played around a little more and noticed these things:

• There is a delay between mouse release when clicking the taskbar button and the window opening. This is caused by the launcher process starting and sending the "open search window" signal to the already running instance of EverythingToolbar. Possibly this time could be optimized. This delay should be constant and independent of whether it's the first time opening the search window or not.
• Toggling the search window using the keyboard shortcut (default should be Win+Alt+S) does not have any delay and feel pretty instant on my machine.
• The closing animation has a lower framerate. This is due to the search window not being focused anymore. WPF will probably assign a lower priority to the animation here. I already looked into that in the past and it's not an easy fix.
• When opening the search window for the first time this will trigger the first search request. Probably this is what you are referring to with slow first launch. Possibly this could be optimized by doing the first search already in the background.
• Updating the search results can cause some flickering as already reported in Search result is flashing when inputing search keyword #89.

Did you observe any other systematic slowdowns?

Oh my gosh, please fix that low-framerate closing animation. It really bugs me a lot

[pa-0]

I will try downgrading and report back, sure. I'd say it's actually a couple of seconds rather than milliseconds. By the way, thank you for creating/maintaining this super useful tool.