home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #26 / NN_1992_26.iso / spool / comp / compiler / 1830 < prev    next >
Encoding:
Internet Message Format  |  1992-11-10  |  2.4 KB
  1. Path: sparky!uunet!ogicse!das-news.harvard.edu!spdcc!iecc!compilers-sender
  2. From: dnl@macsch.com (David Lombard)
  3. Newsgroups: comp.compilers
  4. Subject: Re: Is this a new idea?
  5. Keywords: performance, comment
  6. Message-ID: <92-11-021@comp.compilers>
  7. Date: 4 Nov 92 21:46:37 GMT
  8. Article-I.D.: comp.92-11-021
  9. References: <92-10-124@comp.compilers> <92-10-113@comp.compilers>
  10. Sender: compilers-sender@iecc.cambridge.ma.us
  11. Reply-To: dnl@macsch.com (David Lombard)
  12. Organization: Compilers Central
  13. Lines: 36
  14. Approved: compilers@iecc.cambridge.ma.us
  15.  
  16. In a recent posting, Jawaid Bazyar writes:
  17. >  The only technique that I can think of that's similar to this is called
  18. >"pre-tokenization", and can be used to speed up a compile significantly in
  19. >some types of languages.  Basically, you have an editor which tokenizes
  20. >the source as you type.  Tokenization is, of course, the part of compiling
  21. >that breaks a source program into the individual symbols and what not.
  22. > ...
  23. >  How much speed increase you get depends on the complexity of other parts
  24. >of the compiler.  The speedup for an assembler is massively better than
  25. >the speedup for, say, a C compiler.  The difference is that there is much
  26. >more work after lexing/parsing for high level language compilers.
  27.  
  28. I think he has described the very nature of the problem in this paragraph.
  29. The execution time of any *decent* compiler is not dominated by the
  30. lexical scan, it's the optimization and code generation that costs.
  31.  
  32. Yes, an assembler can benefit greatly (it's a transliteration process
  33. after all).  But a compiler???  No.  That's similar to the argument that
  34. the single operation statement `i++' results in *better* code than `i =
  35. i+1'.  Only a graduate student's compiler would be so unsophisticated as
  36. to actually benefit from the syntax (clearly, the syntax is useful as part
  37. of a larger statement).
  38.  
  39. If tokenizing truly helps a compiler's speed, your compiler can't be doing
  40. much more than producing threaded code, perhaps with peephole
  41. optimizations.  I wouldn't spend too much (time, money, effort) on such a
  42. system.
  43.  
  44. The bold facing you mentioned was also used on the Apple Macintosh Pascal
  45. system, but it was interpreted, and had a *nasty* habit of assuming too
  46. much about the few characters it had seen.
  47. [Maybe, but see Ken Thompson's paper on the Plan 9 C compiler that I
  48. mentioned last week. -John]
  49. -- 
  50. Send compilers articles to compilers@iecc.cambridge.ma.us or
  51. {ima | spdcc | world}!iecc!compilers.  Meta-mail to compilers-request.
  52.