Repository navigation
Performance backlog: lower-impact findings from the audit #17
Copy link
Copy link
Closed
Labels
enhancementNew feature or requestNew feature or request
Description
Lower-impact findings from the same performance audit. Checked items were fixed in #72 (v0.1.4).
- Listings are sorted with
IShellFolder::CompareIDson the UI thread after every load and refresh (nav.rssort_listing). Now sorted on the load worker. - On every repaint, Details view asks the shell again for each visible cell. Icon indexes come from
SHGetFileInfoper 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
GetDisplayNameOfper item (nav.rsshow_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.rsquick_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.rsupdate).
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.rsWM_SHELL_CHANGE). This is older than FIX: CPU and latency (#9-#16), #17 backlog, v0.1.4 #72. - With
icon_theme=defaultturned on mid-session, file types seen during the background export (about 10 s) keep the generic icon until restart, becauseIconTheme::getcaches the miss. - Refresh reselects by ASCII-case-insensitive name, so in a case-sensitive folder a refresh can move the selection from
a.txttoA.txt(nav.rsselection_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
Reactions are currently unavailable
Metadata
Metadata
Assignees
Labels
enhancementNew feature or requestNew feature or request
Activity
FIX: CPU and latency (#9-#16), #17 backlog, v0.1.4 (#72)
CodingDiego commentedon Oct 11, 2026
#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
CodingDiego commentedon Oct 11, 2026
Runtime check of the second-launch hand-off in v0.1.4 (official build, scratch profile, against v0.1.3):
GetMessage(a suspended process) is never reported hung byIsHungAppWindow. 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
FIX: rest of the #17 backlog (#74)