home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #18 / NN_1992_18.iso / spool / comp / sys / mac / hypercar / 3114 < prev    next >
Encoding:
Text File  |  1992-08-15  |  2.0 KB  |  44 lines
  1. Newsgroups: comp.sys.mac.hypercard
  2. Path: sparky!uunet!cs.utexas.edu!wupost!csus.edu!netcom.com!boserj
  3. From: boserj@netcom.com (Jeffrey Boser)
  4. Subject: Re: How magic is the CompileIt?
  5. Message-ID: <8b8m0jb.boserj@netcom.com>
  6. Date: Sun, 16 Aug 92 05:53:23 GMT
  7. Organization: Netcom - Online Communication Services  (408 241-9760 guest) 
  8. References: <15AUG199209103159@oregon.uoregon.edu> <1992Aug16.033156.6692@reed.edu>
  9. Lines: 33
  10.  
  11. sharvy@reed.edu (V Headshape) writes:
  12. > I thought HC 2.0 compiled scripts on its first execution of them and
  13. >stashed them in RAM, so why would compileIt be faster?  At least, why
  14. >would it be 50 times faster?
  15.  
  16. Well, there are some problems here.  First off, Hypercard is
  17. pretty funky when it comes to memory, and the compiled handlers
  18. are all purgeable, so the first memory allocation wipes them.
  19. so this means that they can only hang around for a little while,
  20. and only one at a time.  So its not like its compiled and every
  21. time thereafter you call it, it will be already compiled.
  22.  
  23. Now, me and a few associates hit this problem.  Get this..  what
  24. if you want almost immediate response time from a handler, every
  25. time you call it?  Well, got news for ya, loading the script,
  26. finding the handler, extracting it, compiling it, all take time.
  27. So, what we did was use compile the big handler into an xfcn,
  28. then used ResEdit to mark it to load in when the stack was opened.
  29. Resulting in very fast response, as hypercard only had to figure
  30. out the calling script and go to teh xfcn.  This was a big deal
  31. in that this handler reacted to mouse-presses, and a long delay
  32. before the reaction happened was unacceptable (We got a thousand
  33. percent improvement in speed...  making what it acceptable).
  34.  
  35. Also, depending on *how* your compiled xfcn handles data, there can
  36. be another improvement.  Your xfcn may take advantage of FPU, or
  37. streamline some functions like assignment and arithmetic...  hypercard
  38. is pretty generic, and hence pretty slow in the specific.
  39.  
  40. And..  when it comes right down to it..  if you want response,
  41. hard code the bugger...
  42.  
  43. ....jeff
  44.