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.

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.

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.

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.

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?

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

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.