Angus Robertson - Magenta Systems Ltd wrote:
>> If filling from the registry, better if the list is filled
>> dynamically when a not yet resolved file extension is requested.
> Except that scanning a single registry node or file, allocating memory
> for those nodes, and building indexes for them may be more efficient
> in one function.  

Full ACK, it's one shot, I won't care whether that takes a few 
milliseconds longer or not, more important is _lookup speed. 

> We don't want to open and load a text file each
> time a new type is found.

True, that would be dog-slow.

> I agree that memory is needed for all the MIME types, so it probably
> wants to be a global object shared between multiple servers, maybe
> with the existing code left as a default.

IMO memory use of 200-400 short MIME type strings is minor, nothing
we should worry about today.

> I was only planning on checking:
> [HKEY_CLASSES_ROOT\MIME\Database\Content Type
> Not the full classes root.

OK, may be faster than my test posted previously which still has
room for optimization though.   

> I was also thinking about two indexes, one of MIME types actually
> used, the other the hundreds or thousands that are actually
> registered. 

Lookups from a hash table are hell-fast, until there are collisions.
However with such a small number of key/value pairs lookups will mostly
just take O(1), no need to split the database, if I got your intention 

Arno Garrels
To unsubscribe or change your settings for TWSocket mailing list
please goto
Visit our website at

Reply via email to