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.


Reply via email to