I suspect that Amarok takes up more memory on my computer than it should.
Just starting it and having it in the system tray, ksysguard reports:
amarok 58.5 MB / 42.8 Mb (Memory/Shared memory)
And 6 kio-slaves that is associated with amarok.
4 kio-http 8.6 MB / 6.3 MB (Memory/Shared memory)
1 kio-file 8.4 MB / 3.9 MB (Memory/Shared memory)
1 kio-trash 8.3 MB / 4.9 MB (Memory/Shared memory)

I know shared memory is not easy to understand, but still the individual memory is quite high. And I am not even playing music or doing anything with it.

Is this normal memory consumption?
If not, how can we debug it?

That's all pretty meaningless without a few basic information:

• What exact Amarok version are you talking about?
• Are you running 3rd-party scripts and yes, how many and which?
• What distribution are you using?
• Which exact KDE version is running?
• What are your system specifications (CPU, RAM)?

As a basic rule, Linux uses RAM as available and distributes it between the apps that need it, so just stating Amarok uses a lot of RAM is useless without looking at the whole system.

Right!

Amarok: 2.2.1
KDE: 4.3.4 (from about kde dialog, but about amarok dialog says 4.3.3)

The script management dialog tells me that I have the following scripts enabled:
lyricswiki, Cool streams, Librivox

Dist: Kubuntu 9.10
CPU: Intel(R) Core(TM)2 Duo CPU T7300 @ 2.00GHz
RAM: 3 GB

yeah, my amarok uses 150MB/54,4(shared mem), but it's not a problem really because I have 3GB and not use all of it. I'm just wondering/suspicious because 1.4 didn't use as much.
firefox uses 217MB with 50 tabs open, so i think this one should be the power-user on my system. Also using Kubuntu 9.10.

Beeema wrote:yeah, my amarok uses 150MB/54,4(shared mem), but it's not a problem really because I have 3GB and not use all of it. I'm just wondering/suspicious because 1.4 didn't use as much.
firefox uses 217MB with 50 tabs open, so i think this one should be the power-user on my system. Also using Kubuntu 9.10.

Part of the problem is the "QtScript" bindings we are currently using. They are not very efficient, both memory and performance wise.

However, the good news is, we have a better solution in the pipeline. Stay tuned

markey wrote:However, the good news is, we have a better solution in the pipeline. Stay tuned