Re: metadatabase

On Wed, 2003-10-15 at 13:22, David Hough wrote:
> On Wed, 15 Oct 2003 10:37:00 -0700, Kristian Kvilekval <[email protected]> 
> wrote:
> 
> > On Wed, 2003-10-15 at 10:18, David Hough wrote:
> ...
> > Again how would this co-exist would recursive playlists?
> > Should the current index be of the entire expanded list?
> > Just to be clear the player has it's own idea of a what
> > a playlist is.. The current UI may have several playlists,
> > only one of which needs to be consistent with the player's.
> > For example:
> >
> > Player playsheet
> > 1.  file://song1.ogg
> > 2.  file://myfavorites.m3u
> > 3.  zinf://url?genre=ambient
> >
> > While the UI may show:
> > 1.  file://song1.ogg
> > 2.  +file://myfavorites.m3u
> > 3.     file://song2.ogg
> >         ...
> > 99. +zinf://url?genre=ambient
> >        file://song10.ogg
> >        ...
> >
> >
> > The concept of index may not make too much sense
> > if we allow this.   However, URL's do not and should
> > not need to be unique (though I have seen a request
> > that there be option in the playlist to ignore
> > additional adds of the same song).   I am beginning
> > to think that a position should be a pair
> > (playsheet, index) or even modelled on a tree path.
> >
> > Any ideas?
> 
> I think the tree path is probably the best idea as abstractly thats a 
> reasonable model of what the playlist would actually be like if you 
> started allowing items to be expanded.

So we need some sort of playlist iterator that actually
represents a tree path..

> > Whether loading the database is noticible if *very* dependent
> > on the machine you are running on.   My dually 1.8Ghz athlon
> > at work doesn't seem to mind loading it.  My 466Mhz P-III
> > chokes on it for 20-30 seconds everytime I opened a new browser
> > (old design).   The important thing is that loading
> > of metadata should not be noticable.   Let's leave the
> > decisions of what should be loaded and when it should
> > be loaded in the database modules themselves.  For example,
> > look at the implementations of mdb/gdbmdatabase and mdb/mkdatabase
> > The gdbm needs to preload the entire db in order to support
> > advanced queries..  You could change with a line or two
> > to cache the entries only on the first query.
> >
> You say that the big hit in performance was when opening a new browser. As 
> far as I could ever tell the database was only loaded once, then cached. 
> If this is the case then the real drop in performance was actually due to 
> all the processing required to create the GTK tree (which does indeed take 
> a lot of time) and didn't actually have anything at all to do with how the 
> database was read from disk. You never know, perhaps the old database 
> wasn't actually that slow and it was the browser that was the real problem.

This is correct, loading the database into memory occured only
at startup but was certainly noticeable.  Unfortunately you paid
the price for the database even when you launched zinf to 
play a single song from a browser or the command line.  This could
have been fixed in other ways.  Opening the browser, would then
transfer a cached copy into the tree structure and sort it (over and 
over).   Recent changes made this faster (sort it only once) which
helped quite a bit.  That said, why pay any price when you don't
have to.  I really think we are on the right track with
the musicbrowsermm that loads metadata on demand and a database modules
that load what is needed.   Again, the mdb/gdbmdatabase will loading the
entire the collection into memory (it will also support arbitrary tags).
While the mkdatabase will use memory mapped I/O on system where that is
available.. really there is not much difference except that it 
starts up faster.



-- 
email:[email protected] office:(805)893-4276 http://www.cs.ucsb.edu/~kris



-------------------------------------------------------
This SF.net email is sponsored by: SF.net Giveback Program.
SourceForge.net hosts over 70,000 Open Source Projects.
See the people who have HELPED US provide better services:
Click here: http://sourceforge.net/supporters.php