Significantly improve overall performance and UI responsiveness

[hez2010]

With this PR, UI responsiveness should be significantly improved. For test, just open C:\Windows\System32 and UI almost no longer freezes.

Before (UI freeze everywhere, and after entering System32 the UI froze for several seconds and cannot operate UI):

After (Even using debug build is smoother than before, and there's almost no UI freezes even after entering System32 and WinSxS, you can operate UI immediately):

Change Notes

• Remove unnecessary Task.Run
• Use BulkObservableCollection and suppress CollectionChanged event while loading entries heavily
• Change the workflow of loading entries and applying UI updates:
  • Files and folders list is manipulated on filesAndFolders, which is a List<ListedItem>
  • After manipulation, call ApplyFilesAndFoldersChangesAsync to update UI, which calculate changes incrementally to avoid unnecessary list entry additions as many as possible
  • The BulkObservableCollection<ListedItem> FliesAndFolders should be only used by Bindings and ApplyFilesAndFoldersChangesAsync
  • This change also fixes the unexpected list flash while loading a directory
• Use Task.Run to make list sorting as a background task to avoid UI freezing
• Increase the max value of loadExtendedPropsSemaphore to match the number of CPU processors
• Remove matchingItem lookup in LoadExtendedItemProperties to avoid the possibility of enumerating on a modified list which may crash the whole program. Also matchingItem is unnecessary because the parameter item already comes from filesAndFolders and it's ok if the item doesn't exist in filesAndFolders
• Use an interval sampler to update DataGrid and improve loading performance
• Use a concurrent queue to optimize file monitor, preventing UI lags and possible dead locks when lots of file changes occurred

Note:

• The xlf changes are generated by compilers, I didn't change any language resources
• Cache is preventing files from incremental loading (which can update UI while loading files and won't freeze UI), and it introduces incorrect caching result if user navigate too fast between directories, so I removed it as a temporary workaround.

Contributes to #1769 and #2527 and #3062

[jakoss]

The UI responsiveness is awesome, but file caching removal brings back the most annoying (for me) part that i'm waiting for files to load on every navigation. So i'd argue that it should be refined and integrated, not removed

[hez2010]

The UI responsiveness is awesome, but file caching removal brings back the most annoying (for me) part that i'm waiting for files to load on every navigation. So i'd argue that it should be refined and integrated, not removed

According to my test result, loading 5000 entries only need less than 2 seconds after this PR, which is almost equal to loading those entries from SQLite cache.
Also a cancelled enumeration could result in incorrect cache and there's no way to reset the cache.

Removing the cache is a temporary workaround and I think we can improve the implementation of cache in the future (maybe after this PR).

[jakoss]

5000 entries is very unlikely scenario, we can talk about 20-30 files in folder on average i think? Loading 30 entries from SQLite takes 80 ms at my machine, while loading them from drive takes around 800-1000. Also - SQLite is only second line of cache. Memory cache is significantly faster, it also stores extended properties. Renavigating to visited path is so much faster with this. I know that UI responsiveness is great, but the basic "fast navigation" flow is crucial for productiveness.

You can take a look at this PR: #2944 . It implements preemptive caching, which on fast drives preloads child folders into memory cache.

There is no problem with clearing incorrect cache on enumeration, it's just one event on CancellationToken. Cache is still an experimental option, so it's under active development

[hez2010]

@jakoss Sounds reasonable. I can revert my second commit 50718d7 which removes the cache.
However we still need to figure out a way to load entries from cache gradually so that there won't be too many entries for DataGrid to load at the first time (which may cause a period of time of blank screen).

[jakoss]

@hez2010 I think we could store cache entries as 1 row per file/folder. This way we could even get rid of json serialization. Then on cache load we could "preload" 30 entries and then load the rest, just like during ordinal loading.

Just to confirm - DataGrid have issues with loading a lot of data at once? Maybe simple partitioning of list would be enough (for example https://stackoverflow.com/a/1396143/939133)? Something like: load 30 entries, then add 300, then add 300 etc

[hez2010]

@jakoss For example, if 10k entries are added into ObservableCollection at once, even with my BulkObservableCollection DataGrid will stuck for several seconds in the end. Therefore there'll be a period of time of blank screen before list items being displayed.
~You can simply open C:\Windows\WinSxS (which has at least 20k items) to test this. ~

Current strategy for enumerating files is triggering DataGrid update after 0 (to clear the DataGrid), 32 entries loaded, every 300 entries loaded and the last entry loaded, see https://www.github.com/hez2010/files-uwp/tree/master/Files%2FViewModels%2FItemViewModel.cs#L1176

Update: there's no performance issue with DataGrid even dealing with 10k entries.

[jakoss]

I think we can do similar strategy for preloaded list from cache somewhere here:

Files/Files/ViewModels/ItemViewModel.cs

Lines 814 to 818 in a7479a3

	CurrentFolder = cacheEntry.CurrentFolder;
	var orderedList = OrderFiles2(cacheEntry.FileList);
	OrderFiles(orderedList);
	Debug.WriteLine($"Loading of items from cache in {WorkingDirectory} completed in {stopwatch.ElapsedMilliseconds} milliseconds.\n");
	IsLoadingIndicatorActive = false;

. It would "simulate" gradual loading

[hez2010]

@jakoss Cache fixed via 5c2c108

[hez2010]

I've rebased this PR from master

[jakoss]

Great work, app is now amazingly responsive

[hez2010]

I've added an interval sampler for updating UI which managed to improve the loading performance

[hez2010]

Rebased from main branch.
@gave92 I've made LoadExtendedItemProperties as a background task, could you test again?

[yaira2]

/azp run

[azure-pipelines]

Azure Pipelines successfully started running 1 pipeline(s).

[gave92]

@gave92 I've made LoadExtendedItemProperties as a background task, could you test again?

@hez2010 looks like the issue is solved 👍
Minor issue remaining is that on loading, the gridview "flashes" twice which does not seem to happen on master:

Files.-.Dev.2021-01-18.22-17-59.mp4

[hez2010]

@gave92 This is expected because the collection is changing from time to time while loading entries, which causes GridView to rerender. In master the UI just freeze while loading so there is no flash.

[gave92]

This is due to the fact that bulk observable collection fires a CollectionReset event, right? Which causes the gridview to rerender completely.

[yaira2]

@hez2010 @jakoss Fantastic work on this pull request! This will have a significant impact for everyone who uses Files.

[hez2010]

@gave92 Yes, the CollectionReset event indicates the collection changed dramatically and it's supposed to be, so DataGrid re-renders it completely. There's no AddRange method for ObservableCollection so I think it has to be that.