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
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
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