home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #20 / NN_1992_20.iso / spool / comp / lang / forth / 3141 < prev    next >
Encoding:
Text File  |  1992-09-15  |  2.3 KB  |  55 lines
  1. Newsgroups: comp.lang.forth
  2. Path: sparky!uunet!ftpbox!mothost!merlin.dev.cdx.mot.com!pjd.dev.cdx.mot.com!peterd
  3. From: peterd@pjd.dev.cdx.mot.com (Peter Desnoyers)
  4. Subject: Re: Block versus file
  5. Message-ID: <peterd.716589398@pjd.dev.cdx.mot.com>
  6. Sender: news@merlin.dev.cdx.mot.com (USENET News System)
  7. Nntp-Posting-Host: pjd.dev.cdx.mot.com
  8. Organization: Motorola Codex, Canton, Massachusetts
  9. References: <dak.716483390@messua> <1992Sep14.175419.20951@Informatik.TU-Muenchen.DE>
  10. Date: Tue, 15 Sep 1992 20:36:38 GMT
  11. Lines: 42
  12.  
  13. pazsan@Informatik.TU-Muenchen.DE (Bernd Paysan) writes:
  14.  
  15. >Well, I have thougth quite a long time about the screen vs. stream
  16. >problem. I do not agree withsome of David's points.
  17.  
  18. >DK>Any block structure imposed artificially on the
  19. >DK>top of the file system will be SLOWER than fully utilizing the
  20. >DK>file system.
  21.  
  22. >Almost every file system HAS a block structure below it, and in many
  23. >cases, blocks are a 2^n bytes chunck with n integer and n<=10.  So reading
  24. >a Forth block (1K) is straigt forward, unbufferd and faster than
  25. >arbitrary reading (while "arbitrary" means: less than block size).
  26.  
  27. The concept of buffered I/O has been known for a long time. Forth doesn't
  28. have a monopoly on it. However, the natural read size for most file 
  29. systems that I know of is more in the range of 4K-8K. A reasonable 
  30. interface to the host filesystem will let you read arbitrary blocks,
  31. where arbitrary means any size you can specify.
  32.  
  33. > Even
  34. >for my stream file interface I read and write blocks of 2^n bytes (where
  35. >n depends on what I found useful). 
  36.  
  37. I'm glad to see that you discovered buffering, too.
  38.  
  39. >With scanning for line ends stream
  40. >file interpretation is SLOWER than block file interpretation, although
  41. >less blocks are to read.
  42.  
  43. It's nice to know that your parser is slower on one file type than
  44. another. That really doesn't tell us much about file I/O performance.
  45.  
  46. How about creating a benchmark? Create a large file - say a meg or so -
  47. and read it into program buffers either (1) Forth block by Forth block,
  48. or (2) by using sequential file read commands with a reasonable buffer
  49. size, such as 16K. Both are going to translate to the same file system
  50. requests - the only difference is that the buffer size is going to be
  51. more reasonable in case (2).
  52.  
  53.                 Peter Desnoyers
  54. -- 
  55.