The idea of this topic ids to provide guidelines for minimising Amarok's impact on the system performance. This means

• minimising used RAM
• Making GUI as light as possible to improve speed
• Improving configuration of audio devices to provide campatibility with other software(e.g. Skype)
• Rebuilding Amarok as lightweight player

Why did I create this topic? Because im it's original config Amarok used about 70 mb of RAM, wich is unacceptable for my machine with 512 mb of RAM

Yeah but you can't simply trust the value shown by "top" and similar tools. They don't work reliably on Linux, because shared memory is included. That means that this 70MB you're seeing is actually for the most part shared by other KDE applications as well. The actual RAM usage is lower.

HeadHunter wrote:The idea of this topic ids to provide guidelines for minimising Amarok's impact on the system performance. This means

• Making GUI as light as possible to improve speed
• Rebuilding Amarok as lightweight player

I'm very interested in these topics, too. The only thing I hate about Amarok is it slowness. Examples:

• When I search in the collection it takes some seconds until it updates. In this waiting time the whole player doesn't react anymore.
• I often have to wait some seconds if I change the side tabs from collection to playlists or something else. And the player does'nt react in this time.

My PC: 2 x 1.6 GHz Athlon MP, 2 GB RAM.
My collection: 30,000 files
My system: Slackware current
My Amarok: Currently self compiled and optimized (compilerflags: "-march=i686 -mtune=athlon-xp -O2 -pipe -fomit-frame-pointer") SVN version. The only version that works faster is 1.4.3 but it won't compile anymore on my system. The original Slackware packages are even worse.

@thenktor:

You didn't mention which DB you are using. With 30,000 tracks you definitely want to try MySQL or PSQL.

Mark Kretschmann wrote:@thenktor:

You didn't mention which DB you are using. With 30,000 tracks you definitely want to try MySQL or PSQL.

Yes, I'm using the build in SQlite database because I don't know much about databases and don't want to run one only fpr my music player.
But I could solve my problem for the moment: I have installed 1.4.3 again. My compile problem was something iPod related, so I simply deactivated it.
The waiting time for database searches is now below 1s. Furthermore I didn't notice any waiting time when I switched between side tabs.

I don't know why, but the 1.4.3 is definitely the only 1.4.x version that is so fast for me. I think I have to stick to it.

PS: My configure options for 1.4.3: ./configure --prefix=/usr --without-xmms --without-libvisual --without-opengl --disable-amazon --without-included-sqlite --without-arts --without-libgpod --without-libnjb --without-libmtp

Perhaps it's related to cover arts beeing displayed in collectionbrowser?
But this feature was introduced in 1.4.5!

hurra wrote:Perhaps it's related to cover arts beeing displayed in collectionbrowser?
But this feature was introduced in 1.4.5!

Hmm, I cannot remember if I have tested 1.4.4 but the version before 1.4.3 were slower.

It's definitely worth it to switch from SQLite to MySQL for a large collection.  The speed is much faster, and you don't need to be an expert in databases to use it.  There's a nice tutorial available.

Also please note that Amarok does NOT support downgrading. Whenever you downgrade Amarok to an older version you are risking irreversible database corruption.

Mark Kretschmann wrote:Also please note that Amarok does NOT support downgrading. Whenever you downgrade Amarok to an older version you are risking irreversible database corruption.

Doesn't matter. I simply rebuild the database I don't need the play counters because I use lastfm for this task.

Also note that various kernel parameters can affect performance. Depending on whether you roll your own or use a pre-configured one, it might be worth tweaking things like 'preempt' to better reflect the way you use your system.

dangle_wtf wrote:Also note that various kernel parameters can affect performance. Depending on whether you roll your own or use a pre-configured one, it might be worth tweaking things like 'preempt' to better reflect the way you use your system.

I'm using a dual CPU system with SMP and preempt and 1000 Hz timer frequency.
Linux pinkfloyd 2.6.21.1 #1 SMP PREEMPT Thu May 10 11:08:38 CEST 2007 i686 AMD Athlon(tm) MP 1900+ AuthenticAMD GNU/Linux

@hurra
I think cover arts beeing displayed in collectionbrowser are a big performance impact. They should be loaded in background after all other tasks are done.