View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0021234 | MMW 5 | Main Panel | public | 2024-09-27 12:41 | 2024-10-08 12:40 |
| Reporter | Ludek | Assigned To | |||
| Priority | urgent | Severity | major | Reproducibility | always |
| Status | feedback | Resolution | reopened | ||
| Product Version | 5.1 | ||||
| Target Version | 5.1.1 | Fixed in Version | 5.1 | ||
| Summary | 0021234: Increased memory utilization after navigating (does not go down) | ||||
| Description | We have some mechanisms of caching content/view for the last view or UI compoent for 1 minute and then for the last view (issue #12233 ) for performance reasons But it seems to be broken now and in some situations the cached content seems to be kept forever.. I tested this way (used LowLander's database with > 300K of tracks) 1) Go to Entire Library [List] and let it load all 392592 tracks into tracklist => memory in Task Manager grows near to 1 GB 2) Go to a view that is not showing any tracks (e.g. Playlists) 3) Go to another view that is not showing any tracks (e.g. 'Devices & Services' or empty 'Playing' list) => used memory is still about 1 GB and the tracks are not freed, this can be confirmed by watching DbgView [1636] MM5 [18700](R) MemRAM: 818.4 MB, MemPrivate: 927.2 MB, MemVirtual: 1.3 GB .... [1636] MM5 [18700](R) Allocated TSongListData: 392592, delta: 0 4) wait two minutes => used memory is still about 1 GB !! | ||||
| Tags | No tags attached. | ||||
| Fixed in build | 3061 | ||||
|
|
Testing this and sometimes it works to free the trackslist/memory and sometimes it does not.. Still not found the culprit.. |
|
|
It seems that once the list is fully loaded and cached then it does not leak and is freed.. But when the list is not fully loaded then it leaks forever! |
|
|
Fixed in 3060 |
|
|
This seems partially fixed: 1 Load Entire Library in List View (Column Filter was also enabled) 2 Before fully loading go to Playlist 3 Load Entire Library in List View (Column Filter was also enabled) 4 Before fully loading go to Playlist 5 Load Entire Library in List View (Column Filter was also enabled) 6 Before fully loading go to Playlist --> Memory usage comes down significantly (but remains 50MB over startup memory usage) However if after that: 7 Load Entire Library in List View (Column Filter was also enabled) 8 While loading switch to Grid (by Album) 9 While loading switch to List 10 Before fully loading go to Playlist --> Memory usage remains elevated (~700MB) However: 11 Load Entire Library in List View (Column Filter was also enabled) 12 While loading switch to Grid (by Album) --> Memory usage drops 13 Before fully loading go to Playlist --> but after all these cycles it went from ~250MB at start to ~350MB after idling a bit, so somewhere it's still occupying an extra 100MB while having returned to the opening state. |
|
|
Made some further fixes and optimizations for 3061 (still some room to improve), but it is much better.. Also fixed a possible crash when navigating.. Note that while testing I found that GC (garbage collector) sometimes fires after 30 seconds and sometimes even after minutes, BUT taking heap snapshot (in DevTools > Memory) forces garbage collector to collect the garbage.. So during the tests and after navigation take a heap snapshot in devtools to ensure that it is garbage collected.. And also keep in mind that data sources for the last 3 views are cached (kept in memory) for 1 minute (for the cases when user would navigate back to the same view) |
|
|
Tested 3061 and: - On startup (in the Playing node), utilization is around 300MB - After switching between nodes/views, utilization quickly grows to 465MB - After waiting for 15minutes, memory utilization doesn't decrease even after taking a heap snapshot. Note: this was tested with the DB / environment that I previously shared. p.s. utilization does seem to be improved compared to 5.0.4, so please triage. |
