🚀 go-pugleaf

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