home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #26 / NN_1992_26.iso / spool / comp / compiler / 1826 < prev    next >
Encoding:
Internet Message Format  |  1992-11-10  |  1.4 KB
  1. Path: sparky!uunet!ogicse!das-news.harvard.edu!spdcc!iecc!compilers-sender
  2. From: byron@netapp.com (Byron Rakitzis)
  3. Newsgroups: comp.compilers
  4. Subject: Re: Is this a new idea?
  5. Keywords: parse, performance
  6. Message-ID: <92-11-017@comp.compilers>
  7. Date: 4 Nov 92 08:57:30 GMT
  8. Article-I.D.: comp.92-11-017
  9. References: <92-10-113@comp.compilers>
  10. Sender: compilers-sender@iecc.cambridge.ma.us
  11. Reply-To: Byron Rakitzis <byron@netapp.com>
  12. Organization: Netcom - Online Communication Services  (408 241-9760 guest)
  13. Lines: 18
  14. Approved: compilers@iecc.cambridge.ma.us
  15.  
  16. >[Scanning and parsing can be as much as half of the total time that a
  17. >compiler takes (so says Ken Thompson of his Plan 9 C compiler) and that is
  18. >quite amenable to incremental precalculation. -John]
  19.  
  20. Well, that's Ken's compiler, which doesn't do hairy optimizations, leaves
  21. a lot of work for the loader, and has a fast in-core implementation of
  22. tree passes to boot. ("Turbo C for Unix")
  23.  
  24. I think the %-age for gcc (and I am assuming that most commercial
  25. multi-pass, aggressively optimizing compilers show similar performance) is
  26. considerably lower, around 20%. I am not sure of the figure, it is from
  27. memory from around the time that gcc2 was being released. This would have
  28. been with the optimizer turned on, of course.
  29.  
  30. Sorry I can't be more specific right now.
  31. -- 
  32. Send compilers articles to compilers@iecc.cambridge.ma.us or
  33. {ima | spdcc | world}!iecc!compilers.  Meta-mail to compilers-request.
  34.