Control how much query result items being update at once? Hard cap? Paginated results?

[pc223]

I notice when first time launch Flow and make a query (especially Plugin.Program), the UI of Flow hang a bit, like 2-5 seconds. Probably because of too many query results? (in my testing, the query results count is ~5000 results, related to this #551)

I think it doesn't really have much value to update to UI thousands of results at once.

Maybe a hard cap at number of need-to-update-to-UI-results? Or even better, paginated results?

Paginated results similar to REST API, with requests for next and prev page, results count, seems a bit overkill, but more controlled.

[taooceros]

I don't think Flow will hang for 5000 results in UI update because the use of lazy load image and listview virtualization (which means only the results that is viewable will be updated). From my test, it remains active even with 100000 results (iterating all files from Program Files).

However, it is possible that the program plugin is consuming too much resources because it is executing parallel.

[pc223]

Seems I can only make a long hang with Program plugin, other plugins not clear

[pc223]

It's pretty weird, if I open Flow.Launcher.exe, and query a plugin (ControlPanel) before query the Program plugin, it's fine. So the first time Flow query any plugin, seems to "clear" the "block" somehow.

[taooceros]

Maybe I know what's happening. It has happened a long time ago when I drafting #195.

I will reach out soon since I am doing something else currently.

[pc223]

Maybe I know what's happening. It has happened a long time ago when I drafting #195.

I will reach out soon since I am doing something else currently.

Sure thing!

[jjw24]

hmm i cant replicate with starting up and search for something from programs plugin.

dont limit result though that's a bad design, paginated is fine as long as it is obvious to the user how they can move to the next set and is not slow. but best to find out the root cause.

[taooceros]

I think I failed to reply yesterday. Check out build from #554

[pc223]

When it hangs, the status in Task Manager is "Not responding" and the mouse icon is rotating like below, indicate something block the main thread UI I think. Not sure tho.

I don't think it's the index, all the timing I can measure return back really short (~10ms), all the update results seem done really quickly, I highly suspect the UI event handler of changing results or something like that, not the query code. I suspect the hang happens after this line, not before.

OnCollectionChanged(new NotifyCollectionChangedEventArgs(NotifyCollectionChangedAction.Reset));

Can you give me some testing strategies? Like logging positions or debugging tools, I'm planning to try to build on Visual Studio later.

EDIT:

Confirmed,I set a breakpoint and the hang happens after this line (in BulkAddAll(), not before)

OnCollectionChanged(new NotifyCollectionChangedEventArgs(NotifyCollectionChangedAction.Reset));

[jjw24]

can you give your pc specs please, because i am not able to repro- i am on 16 ram, latest windows 10 update, 4 cores

[jjw24]

also does it happen with actually an installed version of flow not via ide?

[taooceros]

Interesting. I do remember that the bulk update will cause some delay at the first time rendering, which leads me to make small amount of update using normal update method. However, that won't work well for large amount of data changed.

[pc223]

can you give your pc specs please, because i am not able to repro- i am on 16 ram, latest windows 10 update, 4 cores

I'm on a pretty powerful PC, 16ram, 10400 intel, Win10-21H1, but when I use Flow, I tend to open a lot of programs, RAM usage tends to be around 13GB. So I'm still a bit suspect it's related to RAM usage.

also does it happen with actually an installed version of flow not via ide?

Without taooceros's PR #554 , it happens at both, with and without IDE. With that PR, it only happens with IDE in debug mode (release config).

Interesting. I do remember that the bulk update will cause some delay at the first time rendering, which leads me to make small amount of update using normal update method. However, that won't work well for large amount of data changed.

Yeah, so that means the PR #554 is not a root cause solution right? @taooceros But can you reproduce this in your machine?