Memory Usage
The chart below shows memory usage for various open source music players.
The chart above shows a variety of music players. There are some terminal-based music players listed as well as graphical counterparts.
Given the project bills G4Music as lightweight, we were anticipating memory usage would be around the same as other frugal graphical music players. Qmmp, Pragha, MX Music and Sayonara are lightweight graphical music players with memory footprints under 100MB.
However, G4Music weighs in at a hefty 451MB footprint with our default small music collection. That’s disappointing to say the least. To put that into more context, its memory footprint is similar to music players that are Electron-based, a framework renowned for producing massively bloated applications.
Pages in this article:
Page 1 – Introduction / Installation
Page 2 – In Operation
Page 3 – Memory Usage
Page 4 – Summary
Could the unanticipated high memory usage be related to the fact that the G4Music interface is GTK Version 4?
Also from a very quick look at the code, G4Music does not do any decoding or direct playing of the music but sends it off to gstreamer to do the actual decoding and playing (viz sending the audio to the appropriate audio interface pulse, pipewire or whatever). So the G4Music software appears only to be providing a GUI and file and meta-data management and the rest is done by other “Gnome” components
The vast majority of music players rely on frameworks like GStreamer for media processing. So nothing new with G4Music.
I believe GTK4 uses GL and so you end up allocating shared memory by the graphics driver. Also GTK4 uses higher memory for CSS objects and there’s more caching taking place overall than with GTK3-based programs.
Given G4Music gobbles memory as badly as Electron-based junk, I hope not all GTK4 suffer in that regard. Most apps are still using GTK3. Is there a list of GTK4 apps available? It would be interesting to see how much more bloated they are.
Sorry if you thought I was being critical of G4Music using the Gstreamer framework rather than doing the heavy audio processing work its-self. Gnome applications should of course use what is available in the GNOME ecosystem and not reinvent the wheel. The point I was trying to make was that the high memory usage was probably not coming from something in the audio processing part since that was being offloaded.
Perhaps it was unfair to suggest the problem was GTK4 — the problem may perhaps be from a memory leak in the G4Music code its-self and/or how it calls Gstreamer.
If I do a web search on “Gstreamer memory leak” there are quite a few results including from March 2021
“New GStreamer 1.18.4 bug-fix release for our stable 1.18 series. As always lots of bug fixes, stability improvements, and also some memory leak fixes.”
So what version of GStreamer was used in the test performed in the article?
Perhaps those who are testing the application could check to see at what point the high memory usage occurs — right from initialization or later on while it is building its database — and perhaps if time perhaps use a memory profiler on the process.
I don’t really follow GTK4 apps per se but I do know that Pitivi is porting to GTK 4 this summer. A great app
G4Music author here.
About the memory usage, we need more details of your running environment, if you have checked the issues of the project on gitlab, you wil not find any other issues about memory usage.
About the speed of Samba, I guess you must enabled the option “Load thumbnails for non-local files”, it do need more time to parse tags and load thumbnails, just like what Nautilus does. But after GIO cached Samba file, next loading will be faster.
Thanks anyway.
Author of this article
I got the same high memory usage results with both fresh installations of Ubuntu and Manjaro on different PCs.
Re no issues about memory usage on your gitlab, not sure why that’s important. You now know there’s an issue, and it’s easily reproducible.
I am investigating further re the slow network scanning, but again it would be better if you show progress while scanning.
it’s not easily reproducible… I tested in ubuntu 22.04 and fedora 36, with 1500 songs, about 1000 songs has embedded cover art images, it only cost less than 200MB. i guess there are some special song files cause the memory issue, or something else. It’s easy to figure out because it’s open source 🙂
How are you measuring memory usage? Hopefully not with top or a similar utility.
I use ps_mem as it’s probably the best tool for this purpose.
I measured with gnome-system-monitor and htop (by checking the amount of free memory when g4music is running and after quit).
Btw, I found a simplest GTK4 demo app would cost at least 40MB memory, and adwaita-1-demo cost at least 50MB (just launch it no more any actions).
I checked with ps_mem (still same song files):
sudo ps_mem | grep g4music
Private + Shared = RAM used Program
126.9 MiB + 25.2 MiB = 152.1 MiB g4music
How about the private and shared in your case?
The app looks good! But, regarding Samba: I’ve tried setting the app’s directory to my network music directory; I killed the app when it still was loading without any visible progress after two or three hours. Audacious, which is what I’m mostly using, seems to be one or two orders of magnitude faster there.