home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #30 / NN_1992_30.iso / spool / comp / lang / lisp / 3090 < prev    next >
Encoding:
Text File  |  1992-12-15  |  1.5 KB  |  35 lines
  1. Newsgroups: comp.lang.lisp
  2. Path: sparky!uunet!zaphod.mps.ohio-state.edu!cis.ohio-state.edu!news.sei.cmu.edu!fs7.ece.cmu.edu!crabapple.srv.cs.cmu.edu!ram
  3. From: ram+@cs.cmu.edu (Rob MacLachlan)
  4. Subject: Re: Text Processing
  5. Message-ID: <BzBK91.FLG.1@cs.cmu.edu>
  6. Sender: news@cs.cmu.edu (Usenet News System)
  7. Nntp-Posting-Host: lisp-pmax1.slisp.cs.cmu.edu
  8. Organization: School of Computer Science, Carnegie Mellon
  9. References: <723262882.AA00000@blkcat.UUCP>
  10. Date: Tue, 15 Dec 1992 21:12:30 GMT
  11. Lines: 22
  12.  
  13. In article <723262882.AA00000@blkcat.UUCP> Bruce.Feist@f615.n109.z1.fidonet.org (Bruce Feist) writes:
  14. >I'm open to suggestions on how to process text files in Common LISP for
  15. >lexical analysis.  Right now, I'm doing it character-by-character with
  16. >read-char and then using concat to combine the characters I read into tokens;
  17. >is there a better way?
  18.  
  19. If you are doing:
  20.     (setq buffer (concatentate buffer (string char)))
  21. you would be doing better by preallocating a string buffer and growing it as
  22. needed, then taking SUBSEQ at the end of accumulation.
  23.  
  24. >How much more efficient would it be to use read-line and separate tokens from
  25. >each other?
  26.  
  27. It depends on the implementation's relative costs of stream operation overhead
  28. and string allocation.  I would guess that in implementations with
  29. generational GC, the READ-LINE strategy could well be faster.  Most
  30. implementation have internal operations to read a large number of characters
  31. into a preallocated buffer, which could get the best of both worlds at a
  32. portability cost.
  33.  
  34.   Rob
  35.