big problems with gdbm 0.8

Thread View: gnu.utils.bug

2 messages

[T] Back to Threads [V] Tree View [G] Group Articles

2 total messages Started by Chip Rosenthal Sun, 27 Aug 1989 04:12

#378

Author: Chip Rosenthal
Date: Sun, 27 Aug 1989 04:12

25 lines
1463 bytes

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

Re: big problems with gdbm 0.8

#379

Author: Arnold D. Robbins {EUCC}
Date: Mon, 28 Aug 1989 11:14

27 lines
1935 bytes

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

Thread Navigation

This is a paginated view of messages in the thread with full content displayed inline.

Messages are displayed in chronological order, with the original post highlighted in green.

Use pagination controls to navigate through all messages in large threads.

Back to All Threads