search

Flow-Launcher / Flow.Launcher

:mag: Quick file search & app launcher for Windows with community-made plugins
https://flowlauncher.com
MIT License
8.21k stars 317 forks source link

First Query after Flow Launcher starts up is very slow #894

Open Garulf opened 2 years ago

Garulf commented 2 years ago

Discussed in https://github.com/Flow-Launcher/Flow.Launcher/discussions/586

Originally posted by **kubalav** July 21, 2021 I think my fist query take much time (cca 8 sec). After that is blazing fast. I type "git" and it freeze at G. https://user-images.githubusercontent.com/37414585/126500407-8de15b8a-470b-473c-a8e4-c32bcdd74d7a.mp4 Can it caused by this error in log? `Possible interpretation of the error: Unable to get logo for Microsoft.MicrosoftEdge_8wekyb3d8bbwe!MicrosoftEdge from and located in C:\Windows\SystemApps\Microsoft.MicrosoftEdge_8wekyb3d8bbwe`
jjw24 commented 2 years ago

@Garulf can you test this build from https://github.com/Flow-Launcher/Flow.Launcher/pull/893 see if the problem is resolved.

download: https://ci.appveyor.com/api/buildjobs/5aua6t9moqc8i7qb/artifacts/Output%2FPackages%2FFlow-Launcher-Portable.zip

Garulf commented 2 years ago

I'm not seeing any hanging/lag on my installed Flow Launcher or the linked one above. Not sure why I'm not seeing it happen anymore.

EDIT: Definitely seeing lag in the debug version. Perhaps I was running a debug version and didn't notice?

jjw24 commented 2 years ago

@Garulf would you mind double checking again just to be sure please.

jjw24 commented 2 years ago

@kubalav would you mind trying this new build from https://github.com/Flow-Launcher/Flow.Launcher/pull/893 and see if it addresses the above issue please: download: https://ci.appveyor.com/api/buildjobs/5aua6t9moqc8i7qb/artifacts/Output%2FPackages%2FFlow-Launcher-Portable.zip

Garulf commented 2 years ago

Yeah, same as before. Only having the issue in debug mode.

EDIT: Now I'm seeing it again on my installed version...

jjw24 commented 2 years ago

ok i will wait for @kubalav :)

Garulf commented 2 years ago

Now that I'm seeing the bug it doesn't seem to manifest in the bug fix build.

EDIT: Hard to say if it's the bug fix build fixing it or something else...

EDIT2: Still seeing the bug in release build so I say its working?

jjw24 commented 2 years ago

We need to find a reliable way to repro this.

jjw24 commented 2 years ago

Now that I'm seeing the bug it doesn't seem to manifest in the bug fix build.

~EDIT: Hard to say if it's the bug fix build fixing it or something else...~

EDIT2: Still seeing the bug in release build so I say its working?

So it's in release, and no longer in the bug fix build?

Garulf commented 2 years ago

Release is having this issue while the bug fixed build is not. 🤔

jjw24 commented 2 years ago

Ok, that's promising.

kubalav commented 2 years ago

@jjw24 Clean builds (Stable build + build from #893) = no lagging + lagging Imported UserData - build from #893 = no lagging + lagging

I had to reset settings Program & Everything plugins to get rid of lagging in stable build. I wonder how long it will last. I hope forever.

taooceros commented 2 years ago

Sorry do you mean that #893 actually brings lags which does not exist in stable release? Or it resolves the lagging?

kubalav commented 2 years ago

New build brings lagging. I know, it seems to be weird, but that is. On other hands stable release lagging too, but after resetting plugins settings its works without lags.

jjw24 commented 2 years ago

hey @kubalav so build from #893 still lags correct? what about using it after resetting the plugin settings, still lag?

kubalav commented 2 years ago

Oh, no! Stable release lag again. Maybe after restart PC. Anyway, #893 lags after resetting the plugin settings. I investigate that lagging is occurs when I enabled Windows settings plugin + Everything plugin (very small lag cca 2 seconds) or Windows settings plugin + Program plugin with default locations (very small lag cca 2 seconds). If I add bunch of programs to Program plugin results are delayed cca 6 seconds.

github-actions[bot] commented 2 years ago

This issue is stale because it has been open 30 days with no activity. Remove stale label or comment or this will be closed in 5 days.

github-actions[bot] commented 2 years ago

This issue is stale because it has been open 30 days with no activity. Remove stale label or comment or this will be closed in 5 days.

github-actions[bot] commented 2 years ago

This issue is stale because it has been open 45 days with no activity. Remove stale label or comment or this will be closed in 5 days.

LeLocTai commented 2 years ago

If you have problem reproducing, it may be that the clean slate of the build doesn't generate many results. Try copying the data from your live installation into the build's UserData folder. Or maybe make a stress test plugin that generate a lot of results.

Image loading seem to be part of the problem. By noop-ing ImageLoader.LoadInternal, the typing stutter improve a lot, but not completely eliminated, though results still take a while to show up.

A cursory profile indicate a lot of time is being spent on layouting the result list. I don't have very deep understand of WPF, but it look like the virtualization used is only effective for scrolling and not initialization? Maybe we can filter the initial results in some way?

taooceros commented 2 years ago

If you have problem reproducing, it may be that the clean slate of the build doesn't generate many results. Try copying the data from your live installation into the build's UserData folder. Or maybe make a stress test plugin that generate a lot of results.

Image loading seem to be part of the problem. By noop-ing ImageLoader.LoadInternal, the typing stutter improve a lot, but not completely eliminated, though results still take a while to show up.

A cursory profile indicate a lot of time is being spent on layouting the result list. I don't have very deep understand of WPF, but it look like the virtualization used is only effective for scrolling and not initialization? Maybe we can filter the initial results in some way?

Thanks so much for the investigation. I believe the main issue is the WPF layout, which is not something I have deep understand either. The initialization of the results seems not slow, or else it won't happen only at the first time. I guess (maybe I am wrong) the main issue is that WPF hasn't prepared the buffer yet, which leads to very slow initial setup. Further, it only happens when the number of results is relatively large, so I think your guess about virtualization is correct.

Maybe we can wait 500ms to render results that is ranked 100th or more for the first few query.