Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!csd4.milw.wisc.edu!uxc.cso.uiuc.edu!uxc.cso.uiuc.edu!m.cs.uiuc.edu!render
From: render@m.cs.uiuc.edu
Newsgroups: comp.software-eng
Subject: Re: Source Code Control
Message-ID: <39400048@m.cs.uiuc.edu>
Date: 23 Jul 89 22:15:00 GMT
References: <5225@mtgzz.att.com>
Lines: 40
Nf-ID: #R:mtgzz.att.com:5225:m.cs.uiuc.edu:39400048:000:1985
Nf-From: m.cs.uiuc.edu!render    Jul 23 17:15:00 1989


Written 12:19 pm  Jul 10, 1989 by Luis@postgres.Berkeley.EDU:
> I can say in 2 words why traditional RDBMS's and the features cited 
> above are not part of SW eng. tools:
>
>	DISASTROUS PERFORMANCE !!!!!!!
>
>	Runing simple queries on commercial RDBMS's
>takes on the order of 100 msecs on a Sun 3/260.
>With this performance, one cannot hope to do much work
>in a reasonable amount of time
>(I can cite papers on people who have tried but have been defeated by the 
> performance figures). 

From my reading in the area, I've come to think that part of the problem
is implementation-dependent.  There are DBMS machines that can handle
queries very quickly because they've optimized their software and hardware
to support such things.  However, if you take a DBMS like INGRES and put it
on a generic UNIX box, you're going to get performance degradation because of
the incompatibilities between the differing models of interaction. I think a 
solution would be to design an integrated file system/OBMS that supported both 
file and DBMS functions and was optimized for both.  I've heard of various
people trying to build such things, but I can't say how successful they've
been so far.  The results will be slower than a dumb file system, because
you just can't add functionality to a system without suffering some performance
slow-down.  There ain't no such thing as a free lunch.  However, the number
of new, higher-level operations provided should outweigh the slowdown in
older, lower-level operations, and this will be what makes the system 
worthwhile.

>As useful as these services are, until they can be
>provided with reasonable performance, they will be
>largely confined to those areas where they are essential.

Agreed, but the number of areas in which such things are essential is growing.
I don't think you can sell a modern IPSE without DBMS capabilities, and to 
write them off as being too time-expensive is to ignore their usefulness.

Hal Render
render@cs.uiuc.edu