I'm not sure if this is supposed to be normal but I have a not very large music collection and Elisa is consuming 170K of memory. As a point of comparison, juk uses around 70K.
I am working on this. There is this review that improves a little bit the memory consumption: https://phabricator.kde.org/D15456 .
Another review improving memory usage: https://phabricator.kde.org/D15465
Thank you! Do you have any concrete figures as to how much memory has gone down given an "average-sized" library (assuming that memory usage is affected by how many tracks there are)?
I did measurements with htop. They are not necessarily very precise nor reliable. I have measured around 10% reduction in memory usage. I plan to continue working on this but this two reviews are in the quick win category.
A 10% is definitely welcome. It's not that the memory is usage is unreasonably high, but any optimizing is certainly welcome.
Git commit 01c393ec2c0ba1686d03bfbb768df106de6b28f6 by Matthieu Gallien. Committed on 17/09/2018 at 20:43. Pushed by mgallien into branch '0.3'. makes data classes be implicitely shared: decrease memory usage Summary: use QSharedDataPointer to implictely share the data classes (MusicAudioTrack, MusicAlbum and MusicAudioGenre) A little reduction n memory usage is measurable (at least on my setup). A further optimization could be to only create a track once in DatabaseInterface. Reviewers: astippich, januz, ognarb Reviewed By: astippich Tags: #elisa Differential Revision: https://phabricator.kde.org/D15456 M +2 -2 autotests/localfilelistingtest.cpp M +9 -28 src/musicalbum.cpp M +6 -3 src/musicalbum.h M +8 -26 src/musicartist.cpp M +6 -3 src/musicartist.h M +8 -26 src/musicaudiogenre.cpp M +6 -3 src/musicaudiogenre.h M +29 -47 src/musicaudiotrack.cpp M +16 -13 src/musicaudiotrack.h https://commits.kde.org/elisa/01c393ec2c0ba1686d03bfbb768df106de6b28f6
Git commit 773c093b7206e32a869f8fb9ff126be260a132c0 by Matthieu Gallien. Committed on 17/09/2018 at 20:43. Pushed by mgallien into branch '0.3'. add a track cache in database to reduce memory usage Summary: add a track cache in database by avoiding to build new track objects when one already exists fix a few problems once the cache is used Reviewers: astippich, januz, ognarb Reviewed By: astippich Differential Revision: https://phabricator.kde.org/D15465 M +100 -81 src/databaseinterface.cpp M +12 -12 src/databaseinterface.h https://commits.kde.org/elisa/773c093b7206e32a869f8fb9ff126be260a132c0
Git commit 08507e7881f61491c30531b754953deae3693a7b by Matthieu Gallien. Committed on 08/10/2018 at 15:58. Pushed by mgallien into branch 'master'. sets all query to be forward only to save memory saves 10% in memory usage M +70 -64 src/databaseinterface.cpp M +2 -0 src/databaseinterface.h https://commits.kde.org/elisa/08507e7881f61491c30531b754953deae3693a7b
Git commit 84c934cb81a676136b7d7fb57c180df8d004c606 by Matthieu Gallien. Committed on 08/10/2018 at 16:49. Pushed by mgallien into branch '0.3'. sets all query to be forward only to save memory saves 10% in memory usage M +70 -64 src/databaseinterface.cpp M +2 -0 src/databaseinterface.h https://commits.kde.org/elisa/84c934cb81a676136b7d7fb57c180df8d004c606
Git commit fde30aa8c9df54eae1a4cfa04891bd9102fdc160 by Matthieu Gallien. Committed on 25/11/2018 at 19:26. Pushed by mgallien into branch 'master'. improve database performance and reliability Summary: let database test addOneTrackWithoutAlbumArtist have a file database let the numeric unique id starts at 1 instead of 2 let fix warnings from QtCreator in database tests DatabaseInterface: does not emit track changed signals for newly added album artist name is directly a foreign key in Albums should help to ensure greater reliability lists of authors where not working so let's scrap this use the unique fields of Albums for foreign key in Tracks remove TracksArtists Table no longer store tracks count and single disc states in albums table reduce overhead from AllTracksModel reduce overhead of AllAlbumsModel and make it synchronous do not list files too early from Baloo keep all files discovered from a source and fix a minor related issue add a test for DatabaseInterface::askRestoredTracks add albums and artists cache and improve cache usage improve management of files not modified since last scan of music files Related: bug 389136, bug 396607 Test Plan: tests are OK and Elisa application is still working Reviewers: astippich, januz Reviewed By: astippich Tags: #elisa Differential Revision: https://phabricator.kde.org/D16302 https://commits.kde.org/elisa/fde30aa8c9df54eae1a4cfa04891bd9102fdc160
Can you try the latest version of Elisa (or git master, that would be even better) and see if those commits fixed the problem for you? Thanks!
I just tried out elisa 0.4.2. At launch it uses 115 MB. After navigating around and playing a few tracks, etc., it goes up to 145 MB. So there does seem to be an improvement.
Are more improvements expected? Please change the bug status.
(In reply to Christoph Feck from comment #13) > Are more improvements expected? Please change the bug status. I plan to make further improvement later during the current release cycle.
*** Bug 417392 has been marked as a duplicate of this bug. ***
After further improvements, with the git master version, Elisa is down to using only 82 MB of memory for me while playing stuff. That's pretty close to the originally reported memory usage of JuK, so I think we can safely call this fixed! Memory usage will of course increase if you scroll through a huge album art grid, but that's to be expected due to caching. You *want* your memory to be used for this. :)