On Wed, Sep 27, 2000 at 11:28:32PM +0300, Valters Vingolds wrote:
> Hello Chris,
>
> Wednesday, September 27, 2000, 17:47:04, you wrote:
>
> CK> My changes to Metadata to use the HashStore for string storage
> CK> are far enough along to start thinking about getting someone else
> CK> to help test it.
>
> (sorry, haven't looked at it or compiled freeamp lately somehow - it's
> too much of moving target, i guess...;)
>
> Tell you what - I hear a lot from you how your patch segfaults and
> segfaults.
> I don't really hear how it saves megabytes and megabytes of memory.
>
> Do you really think introducing the unstability that will have to be
> debugged and cleaned up for months is absolutely beneficial?
>
>
Elrod Wrote
>
> FreeAmp really does have too large of a memory footprint. It is a shame
> that the STL strings are such memory hogs. I think it is worth seeing how
> big of an improvement his suggestion can bring. If it is not that much of
> an improvement we drop it....right? If it is a big improvement we can all
> hammer on it and track down any lingering issues...
>
> Considering how late in the game Chris is jumping into the code I am
> impressed by how quickly he is modifying the code and getting up to speed.
> It is only natural for there to be bugs and issues when trying to make
> such a large change. Let's give his idea a chance and as much support as
> we can lend and see where we end up.
>
> elrod
These are both good comments. I will clean it up and post the patch
url tonight. [ I don't think anyone over the internet has ever
reviewed my code before. Hmmm.... scary]
shren <[EMAIL PROTECTED]> Wrote:
> I've mostly ignored the freeamp list, but I'll throw in my two bits.
>
> I would have to see some serious numbers on how much memory the patch
> saved. The advantages of using STL strings are very, very numerous. They
> are available for almost every platform, they are pretty well tested, and
> most programmers know how to work with them. My guess is that changing
> string storage methods is not going to make a significant dent in the
> footprint, given that the sound buffer for the music is probably at least
> a half a meg and will only get bigger as better quality music becomes
> common. (At least I'm assuming the buffer size is seconds * bits/second,
> it is in my code.)
String are nice but they are not an optimal database. For instance
freeamp uses gdbm for storing the strings on disk because they form a
DB. My music library had > 9000 empty string objects allocated before
the HashStore patch. Now all those (char *) point to the same null byte
in RAM.
The metadata strings have numerous empty fields and numerous duplicates.
(If done right, the same Artist and Album string will appear over and over).
There are "get" methods that look like
const string MetaData::Artist() {}
That allow the rest of the program to use strings for local processing
without having strings as the inner implementation. (It used to be
const string& when implemented as strings....) I emphasise: the rest
of the program can use "string" as local / temprary storage.
In practice, 96% of the rest of the program called Artist().c_str() or
Artist().size() which eliminated the value of using "string"s. So the
numerous advantages of STL strings are missed. I did not cook up a new
string class: I am using char *. Amateur string classes are a bad
idea.
>From looking at the code, I can see freeamp is meant to scale up to
large music catalogs. For these, the overhead of strings for each
field is not worth it.
---
My perspective:
When I first grabbed the freeamp tarball I could play music, but it
segfaulted as I played with it, so I kept listening to Xmms.
I did much prefer the music browser. The xmms playlist is too primitive.
So I decided my new hobby was helping fix Freeamp. After a few
patches I finially even tracked down the killer DownloadtoString
segfault that the StreamTimer triggered that was my original problem.
The memory footprint is huge. The string storage is being improved,
slowly, with my curent patch. More can be done later with the url
storage. Even more could be done by replacing GtkLabel with a MVC
label that did not have a private copy of the string. (Perhaps some
gtk+ mailing list atchinve has MVC discussions we could search).
Most of the memory footprint will still remain. The goal should be to
get it down to around 10MB. I have seen the beta eat 40MB. For
instance, memory is eaten by playing with Themes that seems not to be
released (I say "seems" since I have only test that causally on one
occasion). Large themes cost RAM, that is not the issue, but trying 6
themes should not eat 6 x large RAM.
-----
My HashStore patch is ...
a) ... easy because only metadata talks to it.
b) ... Hard because C++ memory management is always hard. It only looks
easy when only one strategy is used, and the objects are debugged.
Freeamp talks to too many C libraries to be fully object oriented.
d) ...hard because I made a typo 3 days ago that I only caught last nighit.
c) If Freeamp wants to scale up to the new 75 GB hard drives filled
with gobs of music, then son of HashStore becomes essential. For <
500 song playlists, it is helpful but not critical.
d) ...taking a long time since I only have a pentium 233 to compile it
on for now, and I also have real life to keep up with. Hint: most
files need to be recompiled if you edit metadata.h
-----
As for the searching debate: Freeamp needs good searching. Not a
quick & dirty solution. Something well designed to be very easy with
a good UI, as well as powerful. This is required in order to manage
large catalogs of music. The tree helps, but when some audiofile with
alot of money rips his 1000 cds, he needs a search prompt as well. So
it is worth trying to do it Right (tm) the first time, and so I am
glad there is discussion about how to do it.
-----
Now I am eastern standard time here, so I need dinner.
_______________________________________________
[EMAIL PROTECTED]
http://www.freeamp.org/mailman/listinfo/freeamp-dev
