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).
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. ???)
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?
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.
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
Also, what is FormatExtension?
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?
_______________________________________________
[EMAIL PROTECTED]
http://www.freeamp.org/mailman/listinfo/freeamp-dev
