home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #27 / NN_1992_27.iso / spool / comp / sys / next / programm / 7323 < prev    next >
Encoding:
Text File  |  1992-11-19  |  2.2 KB  |  53 lines
  1. Newsgroups: comp.sys.next.programmer
  2. Path: sparky!uunet!dtint!usenet
  3. From: nevin@dtint.dtint.com
  4. Subject: Re: Coding Rules (NOT rtf)
  5. Message-ID: <1992Nov20.065829.28459@dtint.uucp>
  6. Sender: usenet@dtint.uucp
  7. Reply-To: nevin@dtint.dtint.com
  8. Organization: Digital Technology, International
  9. References: <BxzEsF.60C.2@cs.cmu.edu>
  10. Date: Fri, 20 Nov 92 06:58:29 GMT
  11. Lines: 40
  12.  
  13. In article <BxzEsF.60C.2@cs.cmu.edu> ddj+@cs.cmu.edu (Doug DeJulio) writes:
  14. > In article <1992Nov19.000858.26075@dtint.uucp> nevin@dtint.dtint.com writes:
  15. > >> 3.0 which might tend to reverse NeXT's original position (most of the 3.0
  16. > >> slow-down is related to nib/disk/memory stuff).
  17. > >
  18. > > I've heard a slightly different story about the 3.0 slowdown, from an
  19. > > ex-NeXT employee.  It was caused (according to him) by a
  20. > > generalization of things like "malloc(512)" to
  21. > > "malloc(sizeof(somesuch) * 4)" in order to better support new
  22. > > platforms (ala 486).
  23. > 
  24. > That sort of construct is evaluated at compile-time, not at
  25. > execute-time.  So it would explain a slow-down in compiles, but not in
  26. > general performance.
  27. > -- 
  28. > Doug DeJulio
  29. > ddj+@cmu.edu
  30.  
  31. You're right about that particular construct.  But never-the-less, one of the  
  32. obvious features of "malloc()" is the ability to compute desired block size via  
  33. an arithmetic expression at run-time.  And, it's quite reasonable to choose an  
  34. appropriate arithmetic expression such that the arithmetic expression's syntax  
  35. is constant, and yet it's value changes at run-time depending on the hardware,  
  36. due to architectural differences.  I just threw out a lousy example--from the  
  37. hip.
  38.  
  39. I realize that many such problems could probably be handled via compile-time  
  40. switches and #defines, but I believe it is reasonable to conclude that some  
  41. would fall into the aforementioned category and be computed at run-time.   
  42. Hence, I believe what I was told by the ex-NeXT employee.
  43.  
  44. --
  45. Nevin Pratt, Digital Technology, Int'l    Orem, Ut
  46. NeXTmail preferred, but ONLY at my REAL email address: nevin@dtint.dtint.com
  47.  
  48. -- 
  49. ---
  50. root                                   root@dtint.dtint.com
  51. Digital Technology Int.                (801)226-2984    
  52. 500 W. 1200 South, Orem UT, 84057      FAX (801) 226-8438
  53.