On Sun, 2005-02-27 at 15:23 +0000, Gustavo J. A. M. Carneiro wrote: > On Sat, 2005-02-26 at 12:21 -0500, Matthias Clasen wrote: > >I have tried to incorporate most of the feedback in the next draft of > >the binary metadata format. One question I have not decided yet is > >hashes vs directories: > > > >- do we want hashes ? > >- if yes, where do we want them ? Likely candidates are a hash to > > lookup blobs listed in the directory, and a hash per interface > > to look up the functions in that interface. With the extensibility > > precautions added in the new draft, we should be able to add hashes > > as they turn out to be necessary. > > An interesting idea is to have lazy hashes. The hash table would be > initially empty. When a blob is requested by name, glib would: > 1. lookup the name in the hash table > 2. if lookup succeeds: > 2.a return blob > 3. do linear scan for the blob > 4. add name->blob to hash table > 5. return blob > > This would save on memory (since hash tables cannot be shared between > multiple processes, unlike the blobs) but still provide adequate speed > for frequently accessed items. If you are going to reserve space in the blob for the hash table, you might as well just put the hash table there :-). (It's actually pretty hard to share stuff between processes unless it's read-only.) > One more thing, perhaps it pays off to have a single hash table for > interfaces types + methods. Instead of a tree of hash tables, we could > have a flat hash table, with name mangling, eg. GtkLabel::set_text. > Personally I'm not 100% sure this is a good idea, but I leave the > thought for consideration... The question here is whether looking up a method without having the InterfaceBlob is going to be common. If so, then what you are proposing is more efficient, since it only involves one hash table lookup. But if that isn't a common lookup, then you nteed to spend time making strings and hashing them. (The table could, of course, be hashed with a non-single-string hash table, but that again is additional complexity) Regards, Owen
Attachment:
signature.asc
Description: This is a digitally signed message part