home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #16 / NN_1992_16.iso / spool / comp / sys / mac / programm / 12832 < prev    next >
Encoding:
Text File  |  1992-07-22  |  2.0 KB  |  51 lines
  1. Newsgroups: comp.sys.mac.programmer
  2. Path: sparky!uunet!usc!sol.ctr.columbia.edu!The-Star.honeywell.com!umn.edu!doug.cae.wisc.edu!jverdega
  3. From: jverdega@cae.wisc.edu (Jeffrey Verdegan)
  4. Subject: Re: A few more suggestions for THINK C
  5. Organization: U of Wisconsin-Madison College of Engineering
  6. Distribution: comp
  7. Date: 22 Jul 92 10:31:52 CDT
  8. Message-ID: <1992Jul22.103153.14800@doug.cae.wisc.edu>
  9. References: <SJE.92Jul20180620@xylos.ma30.bull.com> <SRO.92Jul21221949@media-lab.media.mit.edu>
  10. Lines: 39
  11.  
  12. In the discussion of having Think C auto-sement, Shawn O'Donnell writes:
  13. >
  14. >THINK C might be able to make a reasonable first guess at which
  15. >functions should live with which other functions, but you can't tell
  16. >ahead of time which functions will be calling which other functions.
  17. >(The only way you'd know is if your program is independent of user
  18. >input or operates on no more than one data set...)
  19. >
  20. >What would be useful is if THINK C would log code swaps for you 
  21. >while you're developing the code.  Then, if you notice that there
  22. >is a lot of unrest on the heap, you can consider reassigning 
  23. >project entries from one segment to another.  It may already do
  24. >this.  
  25. >
  26.  
  27. This may be a rather naive suggestion, but would it be possible to include
  28. this sort of functionality in the profiler?  Perhaps in conjunction with
  29. MacsBug?  As you can see, I don't have any idea of how all this gobbledygook
  30. works, but I have this vague sense that it should be conceivable that someone
  31. who does would be able to create a profiler kludge to track cross-segment 
  32. calls.
  33.  
  34. This would be enormously useful.  The app I'm developing has around 40 source
  35. files and 10 libraries.  I have a general idea of where the boudaries are that
  36. separate one block of functions that mostly call each other from another, but
  37. I'm willing to bet that, were I to see some numbers, I'd be more than a little
  38. surprised.
  39.  
  40. Jeff
  41.  
  42. ----------
  43.  
  44. Jeff Verdegan
  45. University of Wisconsin-Madison
  46. Computer-Aided Engineering Center
  47. jjv@caestaff.engr.wisc.edu
  48. (608) 263-1875
  49.  
  50.  
  51.