NetNews Usenet Archive 1992 #27/NN_1992_27.iso/spool/comp/sys/next/programm/7324

Text File | 1992-11-19 | 2.8 KB | 69 lines

Newsgroups: comp.sys.next.programmer
Path: sparky!uunet!dtint!usenet
From: [e-mail]
Subject: Re: Coding Rules (NOT rtf)
Message-ID: <[e-mail]>
Sender: [e-mail]
Reply-To: [e-mail]
Organization: Digital Technology, International
References: <[e-mail]>
Date: Fri, 20 Nov 92 07:06:07 GMT
Lines: 56

In article <[e-mail]> [e-mail] writes:
> In article <[e-mail]> [e-mail] (Doug DeJulio) writes:
> > In article <[e-mail]> [e-mail]
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
> > [e-mail]
>
> 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: [e-mail]

Besides, we don't need to get bogged down in "malloc()" details.  There are
plenty of other ways that slow-downs due to code generalizations to accommodate
architectural differences can occur.  I shot from the hip with the "malloc()"
thing in an attempt to illustrate at least one.

--
Nevin Pratt, Digital Technology, Int'l    Orem, Ut
NeXTmail preferred, but ONLY at my REAL email address: [e-mail]

--
---
root                                   [e-mail]
Digital Technology Int.                [phone]
500 W. 1200 South, Orem UT, 84057      FAX [phone]