🚀 go-pugleaf

In article <BxzEsF.60C.2@cs.cmu.edu> ddj+@cs.cmu.edu (Doug DeJulio) writes:
> In article <1992Nov19.000858.26075@dtint.uucp> nevin@dtint.dtint.com writes:
> >> 3.0 which might tend to reverse NeXT's original position (most of the 3.0
> >> slow-down is related to nib/disk/memory stuff).
> >
> > I've heard a slightly different story about the 3.0 slowdown, from an
> > ex-NeXT employee.  It was caused (according to him) by a
> > generalization of things like "malloc(512)" to
> > "malloc(sizeof(somesuch) * 4)" in order to better support new
> > platforms (ala 486).
> 
> That sort of construct is evaluated at compile-time, not at
> execute-time.  So it would explain a slow-down in compiles, but not in
> general performance.
> -- 
> Doug DeJulio
> ddj+@cmu.edu

You're right about that particular construct.  But never-the-less, one of the  
obvious features of "malloc()" is the ability to compute desired block size via  
an arithmetic expression at run-time.  And, it's quite reasonable to choose an  
appropriate arithmetic expression such that the arithmetic expression's syntax  
is constant, and yet it's value changes at run-time depending on the hardware,  
due to architectural differences.  I just threw out a lousy example--from the  
hip.

I realize that many such problems could probably be handled via compile-time  
switches and #defines, but I believe it is reasonable to conclude that some  
would fall into the aforementioned category and be computed at run-time.   
Hence, I believe what I was told by the ex-NeXT employee.

--
Nevin Pratt, Digital Technology, Int'l    Orem, Ut
NeXTmail preferred, but ONLY at my REAL email address: nevin@dtint.dtint.com

-- 
---
root	                               root@dtint.dtint.com
Digital Technology Int.                (801)226-2984	
500 W. 1200 South, Orem UT, 84057      FAX (801) 226-8438