Path: utzoo!utgpu!attcan!uunet!dino!uxc.cso.uiuc.edu!tank!mimsy!chris From: chris@mimsy.UUCP (Chris Torek) Newsgroups: comp.unix.questions Subject: Re: Problems with ndbm Message-ID: <19044@mimsy.UUCP> Date: 12 Aug 89 08:44:01 GMT References: <34200002@zaphod> <34200003@zaphod> <18933@mimsy.UUCP> <36321@bu-cs.BU.EDU> Organization: U of Maryland, Dept. of Computer Science, Coll. Pk., MD 20742 Lines: 19 In article <36321@bu-cs.BU.EDU> madd@bu-cs.BU.EDU (Jim Frost) writes: >My peeve about ndbm is that it doesn't really allow "combined key/data >of up to 4096 bytes". It'll let you *try*, but with larger key/data >combinations, you'll get large numbers of failures on similar keys. >We found that you don't get reliable insertion unless the records are >pretty short (circa 128 bytes; 1024 failed a lot and 2048+ failed much >of the time; for our use anything smaller than 1k was pretty useless). All strings that hash to the same 32-bit value wind up in the same block. It sounds as though you had strings that defeated the hash function. This is not supposed to happen, but you could fiddle with ndbm_calchash() and see if you could get `more unique' values. WARNING: Any change made to the hash function invalidates all old databases. Vendors should tread with care. -- In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 7163) Domain: chris@mimsy.umd.edu Path: uunet!mimsy!chris