chip@vector.Dallas.TX.US (Chip Rosenthal) (08/27/89)
I have ported gdbm version 0.8 to System V (actually XENIX). I have found
several problems with it.
First, gdbm will only work on a machine where:
sizeof(long) == sizeof(int) == sizeof(char *)
To see how big the problem was, I ran lint on it. I got *five* pages of
output.
Second, there are a couple of small bugs in it. The worst is line 195
in gdbmopen() where the for loop scribbles beyond dbf->dir[] and dumps
core.
Third, I am getting really bad performance results. I took a small utility
which uses the system dbm and recompiled it with gdbm. With the XENIX dbm,
it took me 5 seconds to build the database. GNU dbm takes about 90 seconds.
And this is a very small database with only about 300 entires.
This last problem is a real killer for me. Has anybody compared gdbm
against their native dbm? Are the results consistent with what I'm
seeing?
--
Chip Rosenthal / chip@vector.Dallas.TX.US / Dallas Semiconductor / 214-450-5337
"I wish you'd put that starvation box down and go to bed" - Albert Collins' Momarnold@mathcs.emory.edu (Arnold D. Robbins {EUCC}) (08/28/89)
In article <710@vector.Dallas.TX.US> chip@vector.Dallas.TX.US (Chip Rosenthal) writes: >Third, I am getting really bad performance results. I took a small utility >which uses the system dbm and recompiled it with gdbm. With the XENIX dbm, >it took me 5 seconds to build the database. GNU dbm takes about 90 seconds. >And this is a very small database with only about 300 entires. > >This last problem is a real killer for me. Has anybody compared gdbm >against their native dbm? Are the results consistent with what I'm >seeing? Phil has been doing lots of work to improve the code performance. He told me that 0.9 will be around 1.25 NDBM on writes, and perhaps .5 NDBM on reads. In English, writes are about 25% slower but reads about twice as fast! 0.9 will also have an NDBM compatibility interface as well as the current DBM compatibility interface. This is a real boon. I can't comment on how cleanly 0.9 lints, since I haven't looked, and I don't have a very current copy, anyway. So, patience is warranted. GDBM is coming along nicely. I hope Phil won't be too mad at me for talking about unreleased software. -- Arnold Robbins -- Emory University Computing Center | Laundry increases DOMAIN: arnold@unix.cc.emory.edu | exponentially in the UUCP: gatech!emoryu1!arnold PHONE: +1 404 727-7636 | number of children. BITNET: arnold@emoryu1 FAX: +1 404 727-2599 | -- Miriam Hartholz