Perf: Defer file tags database scan off the startup UI path#18615
Perf: Defer file tags database scan off the startup UI path#18615woojh3690 wants to merge 1 commit into
Conversation
|
@woojh3690 we don't mind if contributors use AI in their work, but only if they already have a solid understanding of the codebase. Considering this is your first PR, it would be advisable to first learn your way around the codebase. As a sidenote, we need some time to review the linked issue to make sure we can reproduce the issue on our end. |
|
@yair100 I completely understand. While I do think I reviewed it thoroughly, I also don’t particularly want this PR to be merged. It’s just that, in my environment, this issue has been quite annoying and has made Files very slow. I initially tried to solve it personally, even if that meant forking the project with the help of AI, and that eventually led me to open this PR. If there’s anything I can do to help reproduce the issue, please feel free to ask at any time. Additionally, I’ll add a note to the main text mentioning that it was written with the help of AI. |
Resolved / Related Issues
Why this change is needed
InitializeAppComponentsAsync()resumes on the UI context after quick access initialization and then callsUpdateTagsDb()synchronously. That method recursively enumerates the registry-backed tag index and validates every entry against its FRN, path, and alternate data stream. The work is maintenance rather than a prerequisite for showing the main window.What changed
finallyso a failure in another background initializer does not silently skip tag maintenance.This does not change the registry schema or stored tag format.
Steps used to test these changes
src\Files.App\Files.App.csprojfor Debug x64 without packaging.tests\Files.InteractionTests\Files.InteractionTests.csprojfor Release x64.There are currently no focused unit tests for the registry-backed
FileTagsDatabase; the synchronization paths were additionally reviewed against all currentSetTags,UpdateTag,GetAll, import, export, and ADS write call sites.Status / Follow-up investigation
Further investigation after opening this draft found that the affected user had never assigned a file tag, but the stable package registry hive contained 276,160 empty path-index keys and 95,340 empty FRN-index keys, with zero value-bearing tag records. Normal item loading calls
SetTags()with an empty tag array, and the current registry implementation creates path and FRN keys before removing values, so ordinary browsing can grow an empty tag index indefinitely. The full code-path analysis and hive measurements are documented in #18616.This PR mitigates the visible startup freeze by moving tag database maintenance off the UI thread, but it does not prevent empty-key accumulation or clean existing entries. The root cause in #18616 should be addressed first; this draft can then be evaluated separately to determine whether background maintenance is still needed.
Note: This pull request was created with the assistance of AI.