Skip to content

Performance backlog: lower-impact findings from the audit #17

Closed

Description

@CodingDiego

Lower-impact findings from the same performance audit. Checked items were fixed in #72 (v0.1.4).

  • Listings are sorted with IShellFolder::CompareIDs on the UI thread after every load and refresh (nav.rs sort_listing). Now sorted on the load worker.
  • On every repaint, Details view asks the shell again for each visible cell. Icon indexes come from SHGetFileInfo per row on the UI thread, and every sort or refresh resets them. Cells are cached per row; the first page of icons is filled on the worker.
  • Restoring the selection after a refresh is O(items × selected), with a GetDisplayNameOf per item (nav.rs show_source).
  • Each tab switch reloads the folder and resets the icon and thumbnail caches. Background tabs keep their watch and reload only if they changed, or are virtual or on a network path.
  • Thumbnail requests for rows that were scrolled past stay queued and still get rendered.
  • Search-as-you-type starts a full recursive walk on the first character. The shell walker now stops at the result cap; a minimum query length was not added.
  • Superseded navigations are not cancelled: their loads, Home's build included, run to completion.
  • The elevated USN index is built while holding the cache mutex. The search can now be cancelled; the build still holds the mutex.
  • Copy, Cut, Paste, Delete and Properties build a full context menu, loading every shell extension, just to invoke a canonical verb. CMF_OPTIMIZEFORINVOKE; Copy went from about 350 ms to 80 ms.
  • The sidebar's Pin/Unpin enumerates folders on the UI thread, network paths included (panes.rs quick_access_verb). The breadcrumb chevron part is fixed: it skips network crumbs.
  • The folder tree is synced on every navigation, even while hidden.
  • The text preview loads up to 256 KB into a word-wrapping Edit on the UI thread. 64 KB now, and the same text is not set again.
  • Thumbnails are scaled and alpha-scanned on the UI thread when they arrive. Fitted on the thumbnail worker.
  • Type-to-select scans every item, with three shell calls each, on every keystroke. It reads the cached names.
  • Startup binds the Home folder on the UI thread before the window exists, only to check that it exists.
  • A second launch waits up to 3 s for a busy first instance, then opens its own window. It waits up to 10 s more for a busy, not hung, window.
  • Every clipboard change re-evaluates the command bar, including per-item attribute reads on large selections (commands.rs update).

Found in the #72 review, minor and left for later:

  • Every change notification restarts the 150 ms change timer, so a folder written to every few milliseconds updates only once the writes pause (main.rs WM_SHELL_CHANGE). This is older than FIX: CPU and latency (#9-#16), #17 backlog, v0.1.4 #72.
  • With icon_theme=default turned on mid-session, file types seen during the background export (about 10 s) keep the generic icon until restart, because IconTheme::get caches the miss.
  • Refresh reselects by ASCII-case-insensitive name, so in a case-sensitive folder a refresh can move the selection from a.txt to A.txt (nav.rs selection_matches). Sorting is exact since FIX: CPU and latency (#9-#16), #17 backlog, v0.1.4 #72.
  • After a sort the Shift+click anchor (LVM_SETSELECTIONMARK) stays on the old row position, and the focused item is not scrolled into view.
  • Sorting with a very large selection costs about 0.15 s more per 20k selected rows: it re-sets each row's state. A Ctrl+A selection could move only the focus.

🤖 Generated with Claude Code

Activity

  1. added a commit that references this issue on Oct 11, 2026
  2. CodingDiego commented on Oct 11, 2026

    @CodingDiego
    OwnerAuthor

    #72 (v0.1.4) fixed 12 of the 17 items above, plus some fixes found in its review. The unchecked items, and five minor findings from the #72 review, stay open here.

    🤖 Generated with Claude Code

  3. CodingDiego commented on Oct 11, 2026

    @CodingDiego
    OwnerAuthor

    Runtime check of the second-launch hand-off in v0.1.4 (official build, scratch profile, against v0.1.3):

    • Hung first window (its UI thread blocked in a file open, so Windows reports it hung after ~5 s): both builds open their own window within 1.6 s. The extra 10 s wait is skipped as intended.
    • Busy first window that recovers (unresponsive 4 s, or 9 s): v0.1.4 hands the folder over as a new tab after 4.0 s and 6.5 s. v0.1.3 opened a second window after 3.2 s.
    • New edge, minor: a first window frozen while it was idle in GetMessage (a suspended process) is never reported hung by IsHungAppWindow. v0.1.4 then waits the full 3 s + 10 s before it opens its own window (v0.1.3: 3 s). This only happens with a suspended process, for example under a debugger.

    🤖 Generated with Claude Code

  4. added a commit that references this issue on Oct 11, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    enhancementNew feature or request

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions