On Thu, Sep 28, 2000 at 04:04:54PM -0700, Mark B. Elrod wrote:
> so i did some reading up on stl strings and it appears they are copy on write.
I learn something new every day...usually 7 days after it would have
been most useful to learn it.
> i do
> not know if this is only for instances where you do this:
>
> string foo, bar;
>
> foo = "hello";
> bar = foo;
>
> and not for instances like this:
>
> string foo, bar;
>
> foo = hello;
> bar = hello;
>
> the results that isaac posted seem to indicate that the second case is copy on write
> in which case the char store stuff won't save us any memory.... hmmmm.... need more
> research to confirm/deny this theory.
>
I have too little time for the next few days to find that.
> elrod
>
Except for the case where the string is empty, in which case I
allocate 1 byte which all the empty strings point to ( + 4 bytes for
each char * in the program of course).
--------
I bet C.O.W. string does not compress duplicates:
string a,b;
char * x,y;
x=strdup("Hello");
y=strdup(x);
a=x;
b=y;
free(x)
free(y);
Since to detect this, b would have to search the actual contents of a.
Initializing a string from a char * has to make a copy. So...damn.
Perhaps HashStore should have used string internally. (Like MetaData
did).
--------
Now the guid is in the HashStore as char* so the guid string key in
m_guidTable must make a full copy of it, where before it coould copy
on write. So if HashTable is used, I *have* to fix m_guidTable to use
char* as its key as well. Eliminating duplicate url paths by
splitting into path and filename is independent of this.
Note : m_guidTable is only used 18 lines of code in musiccatalog.cpp
and nowhere else, so it is much easier to change than MetaData was.
But if you split the filename into path&filename then PlaylistItem
would need fixing internally.
I suggest either
a) Reverting my patch and forgetting the whole mess.
b) Keeping HashStore with m_guidTable as multimap<char*, string>
instead of multimap<string,string>
------------------
C.O.W. strins does not fix Gtk widgets. If the current CList and CTree
are duplicating the passed pointers, then for a full playlist there
are 3 copies of the strings.
Too bad the widgets are not using the std::string class.
-------------------
Better Quesion: Can anything else be done about the RAM use? Or is it
all a bloated std c++ library?
I am not up to speed on loadable modules as they are used here. Do they
contain redundant copies of some freeamp .o files?
What is a good memory profiler to find out what object files are using
more memory (for code or data or whatever it can measure) at run time?
-----------------
Anyway, I have no time to code again on this until Saturday.
If we toss out HashStore I can go back to working on GUI improvements,
and thinking about a search interface.
--
Chris.
_______________________________________________
[EMAIL PROTECTED]
http://www.freeamp.org/mailman/listinfo/freeamp-dev
