GNOME Bugzilla – Bug 341593
Less thread use
Last modified: 2010-05-22 11:54:46 UTC
This bug was reported to the Debian BTS. http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=359160 Rhythmbox is espacially slow. Using gdb to trace a recent bug I found that rhythmbox is launching a new thread each time you change the Artist selection in Artist view. I don't think this is a good way to do. Using threads better and stop launching/exiting them all the time would probably save a lot of time.
I strongly doubt that the overhead of starting a thread to run a query could ever make a perceptible difference in response time. Performance improvements are not made based on pure speculation, in any case. If the original bug submitter could provide some data indicating that the use of threads to run queries is a problem, then we would think about changing it. Should this happen, please reopen this bug.
We could probably use the GThreadPool API, and put the query threads (or even better, all the rhythmdb ones) in non-exclusive thread pools. That way we would share threads with other things (like gnomevfs) and during normal use, there would be a spare thread around which would same us creating one.
Created attachment 66896 [details] [review] use thread pool for query threads This patch makes us use a thread pool for query threads, and reaps unused pool threads every 30 seconds.
Committed to cvs. I don't think the other rhythmdb threads would easily be converted to thread-pools without some more substantial modification, so I haven't done that.
May a passer-by ask why the bug is still open if a fix was committed ? (especially considering that it isn't even sure that the thread use is a problem in the first place!)
There are still some other parts of Rhythmbox that use threads for no real reason: the audio CD track scanning, playlist manager saving, and the podcast feed parser. All of these should use asynchronous stuff instead. Use of threads itself isn't an issue, but using them when there are decent alternatives (e.g. asynchronous IO) isn't usually worth the complexity of locking etc.
Created attachment 145594 [details] view of rythmbox threads using htop
Seem to have lost my text here. Try again. I submitted a bug to Ubuntu regarding RhythmBox. They have asked me to raise it here as well. Basically whenever the skip forward button is clicked while RhythmBox is playing it leaves the current thread open and creates a new thread. Going through a library, clicking to the next song on will create lots of dead threads - see attachment.
Your screenshot of htop provides no useful information, and this bug isn't really the right place for it - this is about reducing the number of threads we start, not about fixing thread leaks. Please open a new bug and provide a stack trace. See http://live.gnome.org/GettingTraces for information on how to do this.