yonlu/yellowjacket
1
1 Fork 0
Code Issues 61 Pull Requests 1 Actions Packages Projects Releases 13 Wiki Activity

Tracks view: windowed, server-sorted rows for very large libraries (deferred) #285

New Issue
Open
opened 2026-10-06 02:40:30 +00:00 by yonlu · 1 comment
yonlu commented 2026-10-06 02:40:30 +00:00
Owner
Copy link
Copy source

Deferred, filed so it is not lost (plan 023 step 6).

The Tracks view holds every track in memory so it can sort and filter on the client. With the compact table that is a few MB at 26k tracks and is fine. Somewhere past ~100k tracks it will not be.

The scalable shape is: count first, keyset-paginated rows for the viewport (SQL ORDER BY on the sort column), placeholders for unloaded windows in lit-virtualizer, filtering through the existing FTS (SearchTracks). The cost is that sort and filter become backend round-trips.

Do this when a measured library shows the compact table's decode or heap is the bottleneck — not before.

Deferred, filed so it is not lost (plan 023 step 6). The Tracks view holds every track in memory so it can sort and filter on the client. With the compact table that is a few MB at 26k tracks and is fine. Somewhere past ~100k tracks it will not be. The scalable shape is: count first, keyset-paginated rows for the viewport (SQL `ORDER BY` on the sort column), placeholders for unloaded windows in `lit-virtualizer`, filtering through the existing FTS (`SearchTracks`). The cost is that sort and filter become backend round-trips. Do this when a measured library shows the compact table's decode or heap is the bottleneck — not before.
yonlu commented 2026-10-06 07:05:55 +00:00
Author
Owner
Copy link
Copy source

The measurement this issue asks for, taken on the 50 000-track bulk seed while landing #287:

  • Cold open of Tracks → first row: 1 255 ms.
  • A raw library.Library.GetTrackTable call for the same 50 000 rows: 1 118–1 382 ms.

So essentially none of the second is the TypeScript decode or the render — it is the Go-side query, the column encode, and Wails encoding every result twice for a debug log that is off (#286). That means the first thing to try here is not windowing: it is #286, which would halve the encode for every binding. Windowing is the answer once the payload is bigger than the time to transfer it, and at 10.45 MB (219 B/track) it is not there yet.

Also worth knowing before doing this: the prefetch on nav hover/focus (plan 023) hides most of that second for a pointer or keyboard user, so the case for windowing is a very large library on a slow device — an Android measurement would settle it better than this workstation did.

The measurement this issue asks for, taken on the 50 000-track bulk seed while landing #287: - Cold open of Tracks → first row: **1 255 ms**. - A *raw* `library.Library.GetTrackTable` call for the same 50 000 rows: **1 118–1 382 ms**. So essentially none of the second is the TypeScript decode or the render — it is the Go-side query, the column encode, and Wails encoding every result twice for a debug log that is off (#286). That means the first thing to try here is not windowing: it is #286, which would halve the encode for every binding. Windowing is the answer once the payload is bigger than the time to transfer it, and at 10.45 MB (219 B/track) it is not there yet. Also worth knowing before doing this: the prefetch on nav hover/focus (plan 023) hides most of that second for a pointer or keyboard user, so the case for windowing is a very large library on a slow device — an Android measurement would settle it better than this workstation did.
Sign in to join this conversation.
No Branch/Tag Specified
Labels
Clear labels
Area/Design
Area/Downloads
Area/Explore
Area/Library-UI
Area/Metadata
Area/Packaging
Area/Player
Area/Queue
Area/Settings
Area/Shell-Nav
Compat/Breaking
Breaking change that won't be backward compatible
 Kind/Bug
Something is not working
 Kind/Documentation
Documentation changes
 Kind/Enhancement
Improve existing functionality
 Kind/Feature
New functionality
 Kind/Security
This is security issue
 Kind/Testing
Issue or pull request related to testing
 Platform/Android
Platform/Desktop
Priority
Critical
1
The priority is critical
Priority
High
2
The priority is high
Priority
Medium
3
The priority is medium
Priority
Low
4
The priority is low
Reviewed
Confirmed
1
Issue has been confirmed
Reviewed
Duplicate
2
This issue or pull request already exists
Reviewed
Invalid
3
Invalid issue
Reviewed
Won't Fix
3
This issue won't be fixed
Status
Blocked
1
Something is blocking this issue or pull request
Status
Need More Info
2
Feedback is required to reproduce issue or to continue work
Status
Abandoned
3
Somebody has started to work on this but abandoned work
Status
In Progress
Somebody is actively working on this right now
No labels Area/Library-UI Kind/Enhancement Platform/Android Platform/Desktop
Priority
Low
4
Milestone
No items
No Milestone
Projects
Clear projects
No projects
Assignees
Clear assignees
logan yonlu
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: yonlu/yellowjacket#285