home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #30 / NN_1992_30.iso / spool / comp / sys / acorn / tech / 1097 < prev    next >
Encoding:
Internet Message Format  |  1992-12-21  |  4.8 KB
  1. Path: sparky!uunet!munnari.oz.au!comp.vuw.ac.nz!waikato.ac.nz!aukuni.ac.nz!cs18.cs.aukuni.ac.nz!jwil1
  2. Newsgroups: comp.sys.acorn.tech
  3. Subject: More revelations about RISC OS Lib
  4. Message-ID: <1992Dec19.032638.28814@cs.aukuni.ac.nz>
  5. From: jwil1@cs.aukuni.ac.nz (TMOTA)
  6. Date: Sat, 19 Dec 1992 03:26:38 GMT
  7. Sender: jwil1@cs.aukuni.ac.nz (TMOTA)
  8. Organization: Computer Science Dept. University of Auckland
  9. Lines: 106
  10.  
  11. A hint to the unwary: (That is, people who are still using RISC OS Lib
  12. due to the fact that it infected their programs before they realised how
  13. dangerous it was)...
  14.  
  15. This is a tip which seems very obvious when you think of it, but which
  16. took about 6 months to occur to me, so it may be helpful to others as well.
  17.  
  18. It also might help to convince Acorn to produce a version of RISC OS Lib that
  19. has been split into individual functions (or a proper linker) so that
  20. the problem which I am remedying is reduced/removed...
  21. We all knew the problem was bad, but did we realise it was THIS bad?
  22.  
  23. ---
  24.  
  25. Using LibFile, you can disassemble RISC OS Lib into separate .o files.
  26. This then allows you to remove complete modules from the linking process,
  27. so, for, example, you can replace dbox functions used by your program with
  28. your own code, but still retain the RISC OS Lib interface without the
  29. linker spitting out duplicate definition errors.
  30.  
  31. Why do this? Well, replacing RISC OS Lib code with your own is much much
  32. easier than changing your whole program to do the same thing through a new
  33. interface. Problems also arise where you are dependant on a deep-rooted
  34. module (e.g. event_ or wimp_) which includes calls to another module, which
  35. includes calls to another module. By replacing the calls that (e.g.) wimp_
  36. makes, you can break that inclusion cycle, and make quite a saving.
  37.  
  38. By this method you can replace a whole RISC OS Lib module with *just* the
  39. functions which are actually needed/executed by your program.
  40.  
  41. To show you what a saving you can make, here's a brief burst of very
  42. interesting statistics..
  43.  
  44. In DSEdit, I have removed the following RISC OS Lib modules, and replaced
  45. them with my own C code with the same interface, including *only* the
  46. functions that DSEdit *uses*. The results of this are:
  47.  
  48. Library member              code-size   data-size  Comments
  49. o.NotUsed!.bbc                  2228          32   Pulled in by just about
  50. o.bbc                            664           0   every ROLib module...
  51.  
  52. o.NotUsed!.fileicon              196           0
  53. o.fileicon                       172           0
  54.  
  55. o.NotUsed!.font                 1972           0   To load templates, you
  56. o.font                            28           0   need font_lose() ONLY
  57.  
  58. o.NotUsed!.os                   1072           0   Redirected all os functions
  59. o.os                             476           0   through my own SWI interface
  60.  
  61. o.NotUsed!.sprite               3844           0   ResSpr_ uses sprite_ to
  62. o.sprite                          92           0   init a sprite area and
  63.                 ----          --   load a sprite file...
  64.  
  65. Total RISC OS Lib               9312          32
  66. Less total in DSEdit           -1432         - 0
  67.                 ----          --
  68. Savings:                        7880          32
  69.  
  70. The NECESSARY code linked in from RISC OS Lib is only about 15% of the total
  71. amount ACTUALLY linked in!
  72.  
  73. Quite an incredible saving, especially when you consider that NO functionality
  74. has been sacrificed: The program does everything it did before (and in fact
  75. it now does it more efficiently) 
  76.  
  77. These are just the immediately visible savings - the other thing you get
  78. is increased efficiency, mostly very small, but in some cases to a
  79. quite significant level.
  80.  
  81. For example:
  82.   In an old version of RISC OS Lib (i.e. I can't vouch for it still being like
  83.   this, but if I had any money I'd be willing to bet that it is), to draw
  84.   a rectangle, you call
  85.     bbc_rectangle
  86.  
  87.   This in turn calls
  88.     bbc_move (1 call)  and   bbc_plot (4 calls, to draw the lines)
  89.  
  90.   Now, the bbc_move then calls bbc_plot.
  91.  
  92.   All the bbc_plots invoked then call:
  93.     os_swi3  (to call SWI "OS_Plot")
  94.  
  95.   which in turn calls
  96.     os_swi4
  97.  
  98.   which in turn calls either
  99.     os_swi   or  os_swix
  100.  
  101.   Whichever of these is called then (I presume) actually calls the SWI!!!
  102.  
  103. ...so if we add all of this up, to draw a rectangle, any program using
  104. RISC OS Lib generates something like *** 16 *** completely redundant
  105. function calls!
  106.  
  107. I'm all for hiding the low-level interface with higher levels, but isn't
  108. this stretching the point somewhat? ;-)
  109.  
  110. This may be of little consequence in most places, but in my redraw code (which
  111. uses points and lines somewhat intensively), this equates to a large number
  112. of needlessly wasted CPU cycles...
  113. -- 
  114. _________________  "I'd like to answer this question in two ways:
  115.   /____ _ _/_ __       First in my normal voice, and then
  116.  // / //_//_ /_/       in a silly, high-pitched whine." (Monty Python)
  117.