Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!rutgers!gatech!ukma!xanth!ginosko!uunet!cs.utexas.edu!milano!cadillac!joy!speyer
From: speyer@joy.cad.mcc.com (Bruce Speyer)
Newsgroups: comp.databases
Subject: Re: Extended RDB vs OODB
Message-ID: <2230@cadillac.CAD.MCC.COM>
Date: 14 Aug 89 15:51:47 GMT
References: <3560052@wdl1.UUCP> <411@odi.ODI.COM> <458@cimshop.UUCP> <2177@cadillac.CAD.MCC.COM> <20@dgis.daitc.mil>
Sender: news@cadillac.CAD.MCC.COM
Reply-To: speyer%cad@MCC.COM (Bruce Speyer)
Organization: MCC CAD Program, Austin, TX
Lines: 33

In article <20@dgis.daitc.mil> jkrueger@dgis.daitc.mil (Jonathan Krueger) writes:
>speyer@joy.cad.mcc.com (Bruce Speyer) writes:
>
>>If an application must cross its process boundary in order to
>>communicate with the database system it probably is at least two orders
>>of magnitude too slow.  That is why all of the C++ based OODBMS efforts
>>are using the application memory heap for the cache.
>
>Could you provide some performance measurement data that qualify
>and quantify this assertion?
>
>-- Jon

No, I don't have the numbers or the time to work them up.  Perhaps somebody else
could provide actual statistics and even disprove my assertion.  It would be
interesting to hear from somebody involved with the HP Iris system which is
based upon a relational database.

About 3 years ago I tried putting an electronic information model on top of a
relational system.  It took about 30-40 times longer to netlist a circuit then
it did using a fairly inefficient internally developed memory-based database
system. An operation such as packaging the electronics is much worse since it
must transverse much more of the electronic information model and be constantly
refering to the library portion of the model which was distributed to another
database (making the join operation much more expensive).

Compare the cost of processing a tuple at a time to a C++ style database.  If
the object is in-memory then optimally an indirect reference and a test is all
that is required to transverse a relation or access an attribute.

My apologies for not being able to back up my statements with benchmarks.
Bruce Speyer / MCC CAD Program                        WORK: [512] 338-3668
3500 W. Balcones Center Dr.,  Austin, TX. 78759       ARPA: speyer@mcc.com