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 right. -- Arno Garrels -- To unsubscribe or change your settings for TWSocket mailing list please goto http://lists.elists.org/cgi-bin/mailman/listinfo/twsocket Visit our website at http://www.overbyte.be
