home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #27 / NN_1992_27.iso / spool / comp / lang / pop / 91 < prev    next >
Encoding:
Internet Message Format  |  1992-11-22  |  2.9 KB
  1. From: sfk@otter.hpl.hp.com (Steve Knight)
  2. Date: Sun, 22 Nov 1992 22:50:05 GMT
  3. Subject: Re: Clarity VS Efficiency in POP11
  4. Message-ID: <116670020@otter.hpl.hp.com>
  5. Organization: Hewlett-Packard Laboratories, Bristol, UK.
  6. Path: sparky!uunet!zaphod.mps.ohio-state.edu!usc!sdd.hp.com!hp-cv!hp-pcd!news1.boi.hp.com!cupnews0.cup.hp.com!nsa.hp.com!hpscit.sc.hp.com!scd.hp.com!hpscdm!hplextra!otter.hpl.hp.com!otter!sfk
  7. Newsgroups: comp.lang.pop
  8. References: <TMR.92Nov21122734@emotsun.bham.ac.uk>
  9. Lines: 47
  10.  
  11. In comp.lang.pop, tmr@cs.bham.ac.uk (Tim Read) writes:
  12. > My conclusion is that (bearing in mind I am using an 86 MIP workstation), I
  13. > will not worry about efficiency until I notice that my program is running
  14. > slowly. 
  15.  
  16. It's good to hear from you Tim.  I can only half agree with this view,
  17. though.  One can loosely divide efficiency improvements into 2 types;
  18. local and global.  Local improvements are those that would be confined
  19. to a single procedure (or a well defined collection).  Global improvements 
  20. are those that require changes on a bigger scale.
  21.  
  22. What people tend to talk about when they discuss efficiency are small-
  23. scale local improvements.  And these should not be tackled immediately,
  24. since they are so easy to repair if required.  However, global 
  25. efficiency issues should be designed in from as early as possible.
  26.  
  27. For example, if you have a very large data structure in your program
  28. then you should always consider implementing it via a structured
  29. file.  In one case I was involved in, not so long ago, shifting 
  30. 5Mb of data out of main store onto disc was the critical decision that 
  31. allowed the program to run at all (and thereby determine the more
  32. serious design problems.)  As it happened, the data consisted of a 
  33. linear sequence of floating point values -- so this was exceedingly
  34. easy.
  35.  
  36. > An example of what I mean is using a temporary closure within a
  37. > loop, which looks nice and neat, but will cause extra garbage collections,
  38. > as opposed to using an lblock (As Aaron pointed out).
  39.  
  40. Presumably "lblock" is a typo for "lconstant"?  I would agree that 
  41. worrying about using partial application is foolish.  The current cost
  42. of partial application are due to the design flaw of making closures
  43. mutable.  Because they are mutable, the compiler cannot optimise
  44. even the simplest of partial applications into constants.  I intend
  45. to press for revision of this aspect of POP-11 in the Pop9x work.
  46.  
  47. > Until I notice that it takes longer for the program to run than it does for
  48. > the data to be output, I'll lose no sleep over it....
  49.  
  50. I'll summarise my point here.  If you leave considerations of efficiency
  51. very late then you may miss important design decisions that have to be
  52. made early.  My recommendation is to put efficiency concerns at the top
  53. of the agenda -- along with equally vital concerns such as designing
  54. for debugging.  However, once the broad issues of efficiency are dealt
  55. with it is then a mistake to dabble in the fine detail.
  56.  
  57. Steve
  58.