home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #27 / NN_1992_27.iso / spool / comp / sys / mac / programm / 18750 < prev    next >
Encoding:
Text File  |  1992-11-21  |  2.6 KB  |  66 lines
  1. Newsgroups: comp.sys.mac.programmer
  2. Path: sparky!uunet!spool.mu.edu!sol.ctr.columbia.edu!destroyer!gumby!kzoo!k044477
  3. From: k044477@hobbes.kzoo.edu (Jamie R. McCarthy)
  4. Subject: Re: A few questions on this and that
  5. Message-ID: <1992Nov21.144437.15863@hobbes.kzoo.edu>
  6. Organization: Kalamazoo College
  7. References: <By1vn3.Ctv@news.udel.edu>
  8. Date: Sat, 21 Nov 1992 14:44:37 GMT
  9. Lines: 55
  10.  
  11. kurisuto@bach.udel.edu (Sean J. Crist) writes:
  12. >Greetings all.
  13.  
  14. Hi!
  15.  
  16. >1.  If I'm *shrinking* a handle with SetHandleSize, I don't have 
  17. >to bother calling MemError, right?
  18.  
  19. I've always assumed this;  if it could fail, I'd be _very_ surprised.
  20.  
  21. >2.  If I'm checking MemError, do the contents stay the same no 
  22. >matter how many times I call it (i.e., until the next Memory
  23. >Manager call)?
  24.  
  25. Yes.  It just returns the value of the low-memory global MemErr.
  26.  
  27. >3.  IM warns that menus must not be purged, or a system error will 
  28. >occur.  However, said crash can only occur if somebody refers to 
  29. >the deceased menu, right?  If I purge a menu which I'm sure I don't 
  30. >need any more, and then am careful not to refer to it again (in 
  31. >the MenuBar or otherwise), I should be safe, right?
  32.  
  33. Right.  As long as the _toolbox_ doesn't know about it, it's just like
  34. any other resource, and you're safe.
  35.  
  36. >5.  Does there exist any kind of development tool which ...
  37. >...gives you an average 
  38. >and peak amount of how much space is allocated during the whole 
  39. >run of your application?
  40.  
  41. No, but that _would_ be rather useful...
  42.  
  43. >As it is now, 
  44. >I have to figure out what point of the program is likely to have 
  45. >the highest level of allocated memory and set a breakpoint there 
  46. >to examine things.  This takes a lot of guesswork and time...
  47.  
  48. Time, but not guesswork, really.  Put a _Debugger into your
  49. memory-reclaiming routine, so you'll get tipped off when it's called.
  50. Then set your app's heap to as low as you think it'll run under, and run
  51. it.  If it gets called, check the stack crawl and you now know where
  52. you're in trouble--you might want to bump the app heap up a little to
  53. make sure you're near the "peak" point.  If it doesn't get called,
  54. decrease size and try again.
  55.  
  56. Then put _Debugger before and after the "peak" point, and when you hit
  57. the debugger, set breakpoints on the _NewHandle and _NewPtr traps, so
  58. you can watch what's going on.
  59.  
  60. It does take time.  But it's not hard to get a very clear picture of
  61. what your app's doing.
  62. -- 
  63.  Jamie McCarthy      Internet: k044477@kzoo.edu      AppleLink: j.mccarthy
  64.  "I don't think we should have to have them wandering the streets
  65.   frightening women and people."                            - Pat Buchanan
  66.