home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1993 #1 / NN_1993_1.iso / spool / comp / lang / pascal / 8000 < prev    next >
Encoding:
Internet Message Format  |  1993-01-09  |  3.0 KB

  1. Path: sparky!uunet!munnari.oz.au!ariel.ucs.unimelb.EDU.AU!ucsvc.ucs.unimelb.edu.au!lugb!lux!cscmd
  2. Newsgroups: comp.lang.pascal
  3. Subject: Re: Faster Pascal
  4. Message-ID: <1993Jan9.140610.28269@lugb.latrobe.edu.au>
  5. From: cscmd@lux.latrobe.edu.au (Mitch Davis)
  6. Date: Sat, 9 Jan 1993 14:06:10 GMT
  7. Sender: news@lugb.latrobe.edu.au (USENET News System)
  8. References: <mitchell.11@odie.ee.wits.ac.za>
  9. Organization: La Trobe University
  10. Lines: 55
  11.  
  12. In article <mitchell.11@odie.ee.wits.ac.za> mitchell@odie.ee.wits.ac.za (MITCHELL JAMES) writes:
  13. >G'day all!
  14. >
  15. >Bascially, I'm trying to find a way to run Pascal code faster. I have access 
  16. >to a 486 but this is woefully inadequate (for my needs at least).
  17.  
  18. Hi there James!
  19.  
  20. >If anyone has experienced/solved the speed problem, I would greatly 
  21. >appreciate their advice.
  22.  
  23. I've had that problem, and I've solved it.  90% of the time, you can
  24. triple the speed of your program by re-writing it so it is smarter.
  25.  
  26. I'm wondering just what sort of program you're running.  As far as PC
  27. languages go, Turbo Pascal is no slouch.  In fact, Turbo's speed is such
  28. that running your Pascal program on another platform even three times
  29. faster is highly unlikely to yield a three-fold improvement.
  30.  
  31. Here's an example:  At the moment I'm working on a program which reads 
  32. email into a BBS message base.  In Fidonet, the standard for transferring 
  33. messages is in .PKT files.  My program (written 95% in TP and 5% in BASM) 
  34. will currently read and process 1 Meg of .PKTs (that's about 950 messages) 
  35. in 14 seconds (on a 16MHz 386). [*]
  36.  
  37. On my first version of the program, my main speed problem was the
  38. massive overhead each time you call DOS for some more of the file.  It
  39. took me months of thinking to devise a way which still uses DOS calls,
  40. but avoids this enormous overhead.  
  41.  
  42. My point is, make sure the program you are running is running as
  43. efficiently as possible.  If you have ANY heap left over, use it to
  44. build tables which will reduce computation.  If you're doing any sort of
  45. data structure access (random OR sequential, in memory OR on disk),
  46. cache the last few elements accessed, so that you don't have to go
  47. seeking around for it, or writing to the same spot multiple times.
  48.  
  49. These are two of the tricks I've found MOST useful lately, and it's
  50. tricks like these that can make the difference between wanting a faster 
  51. machine, and swearing that the program is faulty because "there's no way 
  52. the thing can be finished in that short amount of time!"
  53.  
  54. >James Mitchell
  55.  
  56. Mitchell James Davis.
  57.  
  58. [*] Those involved in Fidonet might be interested.  I'm writing this
  59. program because of the woeful performance and features of the programs
  60. used with TBBS.  Currently, TMAIL takes about **95** minutes to import 3
  61. megabytes of mail into a 23 megabyte database, age old messages, keep
  62. quotas, export local messages, link subject headers, compress the
  63. database, and a few other jobs.  My program which replaces and enhances 
  64. TMAIL is currently doing the same job in **under** 7 minutes.
  65.  
  66. I hope it sells.  Otherwise I won't have any money to buy food this year!
  67.