Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!wuarchive!cs.utexas.edu!uunet!mcsun!corton!inria!seti!adele.inria.fr!pete
From: pete@adele.inria.fr (Pete Keleher)
Newsgroups: comp.sys.mac.programmer
Subject: Re: How to malloc memory VERY dynamically and not out of app heap?
Message-ID: <2043@seti.inria.fr>
Date: 2 Apr 91 07:21:10 GMT
References: <1CE00001.binbdde@tbomb.ice.com>
Sender: news@seti.inria.fr
Organization: INRIA, Le Chesnay - France
Lines: 39

In article <1CE00001.binbdde@tbomb.ice.com>, time@ice.com (Tim Endres) writes:
|> 
|> In article <2029@seti.inria.fr>, pete@adele.inria.fr (Pete Keleher) writes:
|> > 
|> > I disagree. You are saying that each application should manage its own
|> > virtual memory. It is precisely to avoid this that we have
|> > application-independant virtual memory supported by the system. If you want
|> > to read a 10meg file, read into memory and let the system page it on and
|> > off of disk.
|> 
|> OH Please do! And my commercial product will beat yours hands down
|> EVERY time! When you force the user to sit through a 10Megabyte move
|> of data from one place on their hard disk to another place JUST so
|> they can read the first page of the file, your product is history!
|> 
|> Just another classic example of a "computing thoery" mindset missing the
|> "practical world" mark by several miles. As I have told every student
|> of programming I have ever taught:
|> 
|> 	"Use your head for more than syntax checking!"
|> 
|> We do not hire CS majors. They make terrible programmers. :)
|> 
|> tim.

How often do you read 10meg files, Tim? Do you want every application to
throw out a clean simple design in favor of re-implementing system services
just so that 10meg file can be read in a little faster? Meanwhile, code
complexity is greatly increased, code size as well.

Computer science majors are taught to think in terms of abstractions.
Optimize for the common case. If the 10meg file is your common case, then
you aren't looking for a general purpose editor.

-- 
						Pete Keleher

INRIA, B.P. 105, 78153 Rocquencourt Cedex, France.  Tel.: +33 (1) 39-63-52-93;
fax: +33 (1) 39-63-53-30; e-mail: pete@sor.inria.fr