On 24-Sep-2000 Chris Kuklewicz wrote:
> First:
>
> I have written/compiled charstore.h and charstore.cpp which implement
> the API for storage of reference counted char* string. The overall
> idea is to reduce storage size even though operations may take longer.
> There is an abstract interface and two actual classes:
>
> AbstractStore which defines the api methods, and documents the semantics.
>
> HashStore which uses both a hash_set<> and a hash_map<> so it is space
> and time efficient for large string collections. The hash set of
> refcount==1 strings is accessed first so it is fairly optimised for
> strings that are never duplicated (e.g. GUID).
Just fyi, GUIDs can be duplicated -- I have a few tracks in my collection that
are identical, just on separate albums.
> StringStore which uses a single map<> to keep the strings in a sorted
> order. It is less space efficient than the hash_set in HashStore if
> there are few or no duplicated strings. Keeping it always sorted is
> slower than using a hash based container. The advantage is only for
> items that need to be read out in a sorted order. (e.g. ???)
I don't see any reason to keep it sorted.
> The API works best for dynamically allocated strings, but it is
> kludged to handle "static" strings that are never freed.
>
> The API is not for storing "mutable" strings. If you want to change
> the title, you have to unref the old title and store the new one.
> Is this a problem anywhere?
Shouldn't be a problem.. The access methods of the Metadata class are all
const, so if anyone was playing w/ them, there should be compiler warnings, and
I haven't seen any of those from that..
> Second:
>
> Now how to perform the radical surgery?
>
> Following the "data path"...the Read/WriteMetadataFromDatabase use the
> MetaData get/set functions to store the strings. So the MetaData
> class is the primary target: keep the api but change the storage to
> the new charstore.h classes.
Right -- should be able to just change the access/set methods of the MetaData
class, and it _should_ work.
> So how does the lightweight metadata class lean about the concrete
> storage classes? Simple: Declare the storage classes during program
> initialization and put pointers into the FAContext. Then make a class
> static variable m_context in MetaData that points to FAContext and set
> it during program initialization. This also seems to solve telling
> the windows dll's where the freestore is.
>
> So the Meta class has storage for
> Artist, Album, Title, Comment, Genre, FormatExtension (?), Year, GUID.
>
> Do any of those need to be pulled out in sorted order?
> Artist: we need a sorted artist list for the musicbrowser tree.
> Title: Is the "all songs" tree list in sorted order
Don't need any sorting -- see base/src/musiccatalog.cpp, it handles storing
things sorted, and the GUI code in the musicbrowsers can handle sorting as well.
> Also, what is FormatExtension?
The extension of the file associated w/ the metadata -- I wasn't aware anything
used this.
> At first, I will simply store all of the fields in one huge HashStore.
> If the hash is reasonably efficient the large size will not affect
> performance.
>
> Note: Splitting the url into pathname and filename for efficiency will
> not be attemped till much later. I have not studied the m_guidTable
> closely yet.
>
> Third:
>
> Thread safety. How is the current sting storage protected? I can
> easily add a mutex to protect the stores, but I ought to understand
> the current system. Help?
Isn't really any protection currently, except what's inherent in the STL.
Isaac
_______________________________________________
[EMAIL PROTECTED]
http://www.freeamp.org/mailman/listinfo/freeamp-dev
