Skip to content

Perf: Defer file tags database scan off the startup UI path#18615

Draft
woojh3690 wants to merge 1 commit into
files-community:mainfrom
woojh3690:perf/defer-file-tags-db-scan
Draft

Perf: Defer file tags database scan off the startup UI path#18615
woojh3690 wants to merge 1 commit into
files-community:mainfrom
woojh3690:perf/defer-file-tags-db-scan

Conversation

@woojh3690

@woojh3690 woojh3690 commented Jun 19, 2026

Copy link
Copy Markdown

Resolved / Related Issues

Why this change is needed

InitializeAppComponentsAsync() resumes on the UI context after quick access initialization and then calls UpdateTagsDb() 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

  • Run the tag database scan after the existing non-critical background initialization instead of blocking the UI thread.
  • Execute the scan from finally so a failure in another background initializer does not silently skip tag maintenance.
  • Log failures from the fire-and-forget initialization task.
  • Serialize registry path/FRN index operations and ADS writes because they are multi-step updates and can now overlap with user actions.
  • Keep each scanned item atomic rather than locking the entire scan, avoiding a long wait if the user applies a tag while maintenance is running.
  • Update paired database and ADS writes through one helper and show write-error UI only after releasing the lock.

This does not change the registry schema or stored tag format.

Steps used to test these changes

  1. Built src\Files.App\Files.App.csproj for Debug x64 without packaging.
  2. Built and signed the Release x64 sideload MSIX bundle with the same package settings used by CI.
  3. Verified the generated MSIX bundle signature successfully.
  4. Built tests\Files.InteractionTests\Files.InteractionTests.csproj for Release x64.
  5. Manually installed and launched a sideload package containing the background deferral; the user reported that the main window became responsive much sooner. The final synchronization follow-up was build and package verified.

There are currently no focused unit tests for the registry-backed FileTagsDatabase; the synchronization paths were additionally reviewed against all current SetTags, 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.

@woojh3690 woojh3690 changed the title Fix: Defer file tags database scan from UI thread Perf: Defer file tags database scan off the startup UI path Jun 19, 2026
@yair100

yair100 commented Jun 19, 2026

Copy link
Copy Markdown
Member

@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.

@woojh3690

woojh3690 commented Jun 19, 2026

Copy link
Copy Markdown
Author

@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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants