Mirage uses a lot of memory during analysis and during playlist generation

[GoogleCodeExporter]

With a library of about 13000 tracks, memory usage was at 700MB at the end
of the analysis, and memory usage goes from 50MB to 120MB when generating a
new playlist.

Original issue reported on code.google.com by bertrand.lorentz@gmail.com on 8 Aug 2008 at 3:32

[GoogleCodeExporter]

By using valgrind I detected a small leak in libmirageaudio that is now fixed.

The memory usage on playlist generation seems to be caused by the fact that we 
end up
going through each line of the mirage DB and compute the distance for its scms.
It would be nice if we could select a subset of the tracks, for which we would 
then
calculate the distance. This preselection would be done using a pre-calculated 
field
in the DB, something like a "mean", representative of the scms.

Original comment by bertrand.lorentz@gmail.com on 11 Aug 2008 at 7:02

[GoogleCodeExporter]

Ways to improve memory usage:
 * We could get rid of the Scms class and store similarity model of a song in an
array, this could also speed up similarity computation...

 * Do not serialize/deserialize the Scms model, store the data explicitly.

Unfortunately there's no way to compute a mean-representative of multiple scms 
models
and get rid of the sequential scan through the database.

Original comment by dominik....@gmail.com on 31 Oct 2008 at 3:49

[GoogleCodeExporter]

Another idea about this :
We could pre-compute the distances between all Scms and store this data in the 
DB. Of
course, that would mean that for a library containing N tracks, we'll have 
N*N/2 entries.

Original comment by bertrand.lorentz@gmail.com on 2 Nov 2008 at 1:48

[GoogleCodeExporter]

Hm, precomputing would make updates of the database (delete- and add-songs) more
complicated, building the database would take very long and take huge amounts of
memory. I'd rather try speeding up the distance computation function.

I just fixed the memory leak in gst-mirageaudio.c, which made banshee consume 
so much
memory during analysis of a music collection.

Now I need to write test-programs to ensure that all changes in the 
Audio-Analysis
part work as planned (Issue #14 and #9)...

Original comment by dominik....@gmail.com on 5 Nov 2008 at 4:34

[GoogleCodeExporter]

I just verified your bug report with the latest revision, this is fixed.

During analysis of 5100 tracks memory stayed constantly at 86MB.
During playlist generation memory is capped too, since we currently load only 
100
models at a time. Memory stays at around 72MB for the 5100 tracks collection.

Original comment by dominik....@gmail.com on 4 Mar 2009 at 11:03

• Changed state: Fixed