|
|
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. |
|
|
I've been inspecting leaks today and found a huge leak when editing auto-playlists, with each edit of auto-playlist the list of new tracks is kept in memory until user changes view.. i.e. 10 edits to auto-playlist with 80K tracks causes that there is 800K tracks in memory! Changing view to another node and back frees the memory.. This is related to handling view.promise() function.. |
|
|
But even when the data is freed after changing to another view and back, the used memory still remains at 530 MB which corresponds to the Chromium's memory management that somehow keeps the memory as reserved for the future usage.. :-/ image.png (106,307 bytes) |
|
|
..which I confirmed by re-allocating another 860K tracks and the memory still is 530 MB image-2.png (56,146 bytes) |
|
|
Fixed in 2024.1.0.3105 |
|
|
Verified increase in 3108 over 6h usage. Increase is less than 25mb. |
- Anonymous
