GNOME Bugzilla – Bug 342333
reduce size of RhythmDBEntry
Last modified: 2010-05-22 11:55:14 UTC
Currently we store a pointer to a GDate in RhythmDBEntry, only allocating a GDate for entries that actually have date information. We could store the GDate itself in the db entry, as the structure contents are public, saving one malloc per entry with a date, wasting the difference between the size of the date structure and the size of a pointer for each entry without. sizeof(GDate) is 8 bytes on a 32bit machine. The proportion of entries with date data doesn't have to be all that high for 8 bytes per entry to be less than 4 bytes per entry + (8 bytes + malloc overhead) per entry with a date. I'm not sure how this adds up on 64bit machines, though.
Created attachment 65815 [details] [review] patch also changes the query preprocess function to use a GDate on the stack, but that doesn't really achieve anything.
(In reply to comment #0) > Currently we store a pointer to a GDate in RhythmDBEntry, only allocating a > GDate for entries that actually have date information. We could store the > GDate itself in the db entry, as the structure contents are public, saving one > malloc per entry with a date, wasting the difference between the size of the > date structure and the size of a pointer for each entry without. Removing this kind of thing is probably very beneficial, since I've seen massif reporting that 10-20% of RB's heap is taken up with heap-management overhead. Reducing the number of objects pointlessly allocated in the heap would be good. The patch looks sane to me. > sizeof(GDate) is 8 bytes on a 32bit machine. The proportion of entries with > date data doesn't have to be all that high for 8 bytes per entry to be less > than 4 bytes per entry + (8 bytes + malloc overhead) per entry with a date. > I'm not sure how this adds up on 64bit machines, though. The glib docs state that GDate uses a bitfield because it should be able to be packed into an int on 64 bit machines. So assuming that pointers are also 64 bits, it would be break-even if nothing has dates, and gain for anything else. On a related note (which should probably be a separate bug), there are several easy things we could do to shrink the side of RhythmDBEntry: 1) make the replaygain values be float instead of double, the extra precision is fairly pointless here. 2) rating doesn't need to be a double either. If we really wanted, we could even use a unsigned char and scale the values into 0-255. 3) use a bitfield instead of gbooleans 4) reorder the fields to get better packing
I've committed the patch. We might as well leave this bug open for the other entry size reduction ideas.
Looks like entries are allocated with plain g_malloc. Isn't this a perfect job for the slice allocator? About shrinking replaygain values: The gains even fit into 14 bits since the analysis precision is just 0.01 dB, range -55.18...+64.82 dB. Should do absolutely no harm to store the peaks in just 16 bits also (or even 15).
Not much point keeping this open.