gnump3d-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Gnump3d-devel] [PATCH] Updates to the tag cache


From: Steve Kemp
Subject: Re: [Gnump3d-devel] [PATCH] Updates to the tag cache
Date: Sat, 19 Feb 2005 21:30:29 +0000
User-agent: Mutt/1.3.28i

On Tue, Feb 15, 2005 at 02:48:19PM -0500, Stuffed Crust wrote:
> 0) A few formatting and typo fixes.

  Cheers, sometimes my typos are quite bad!

> 1) SIGHUP tells gnump3d to reload the cache.  It's currently implemented 
>    such that the "reload check" happens in the main loop, but post-fork.
>    The original "auto-reload" test was removed, as it was badly broken, 
>    happening post-fork in each child.  (That was my code though, so I 
>    suppose I cnan't blame anyone but myself..)

  Looks good, committed.

> 2) Convert the tag cahche to be a hashmap of hashes.  This makes the 
>    overall memory usage slightly worse, but increses the runtime speed a 
>    bit, especially for large directories.  Before, the file returned us 
>    an array of key=value pairs, which we then converted into a hash on 
>    each request.  On my collection, this has a ~3% memory penalty and a 
>    noticable boost in runtime speed.

  Also observed here.  I guess it's a tradeoff really memory vs. speed.

  Sometimes I get complaints that the code is slow, especially in a
 recursive playlist generation on an old machine.  I'm not sure whether
 this will help people in that situation or not, still it looks good
 and works for us so I've committed it too.

> 3) have the "valid" test skip empty tag keys and also mtime, which was 
>    always present, thus mucking up the display of files lacking valid 
>    ID3 tags.

  Yeah. D'oh.  Thanks.

> I'm also working on a method to update the stored tag cache on the fly, 
> so we don't need to manually re-run gnump3d-index to pick up those extra 
> files.  

  I think I said in a previous reply this seems like a good plan.

> Lastly, I'm debating changing the behaivor of the "NEW" notification -- 
> it makes more sense to compare it against the last tag cache update 
> rather than the server startup time.   Using this mechanism we can 
> also detect new files as well.  Thoughts?  (obviously my idea of 
> updating the cache in real-time changes this a bit)

  Yes .. Some people have suggested showing new files is more useful
 than new directories.  (I guess this is a personal thing, I only add
 new files in new directories so these are synonymous for me).

  If you patch it for this I will accept it.

> Anyhoo, back to the bit mines.

  :)

  As always your patches are greatly appreciated, thanks.

Steve
--
# Debian System Administration
www.debian-administration.org/





reply via email to

[Prev in Thread] Current Thread [Next in Thread]