home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #18 / NN_1992_18.iso / spool / comp / softsys / andrew / 1160 < prev    next >
Encoding:
Text File  |  1992-08-21  |  3.7 KB  |  71 lines
  1. Newsgroups: comp.soft-sys.andrew
  2. Path: sparky!uunet!decwrl!adobe!usenet
  3. From: zstern@adobe.com (Zalman Stern)
  4. Subject: Re: More checks on size of ATK applications
  5. Message-ID: <1992Aug21.214054.4900@adobe.com>
  6. Sender: usenet@adobe.com (USENET NEWS)
  7. Organization: Adobe Systems Incorporated
  8. References: <14207@auspex-gw.auspex.com>
  9. Date: Fri, 21 Aug 1992 21:40:54 GMT
  10. Lines: 59
  11.  
  12. Its strange to drop in here every now and then and find out that nothing has  
  13. changed in three or four years...
  14.  
  15. The original goal of runapp was to use standard UNIX shared text mechanisms  
  16. to simulate shared libraries. (At the time, we referred to this as an  
  17. "upside down" library approach. The original idea was either Andy Palay's or  
  18. Tom Neuendorffer's. I believe it was Mike Kazar who coined the term  
  19. "pinapple upside down library.") This was at about the tail end of the time  
  20. when the ITC was incredibly concerned about memory usage. (Shortly  
  21. thereafter it became a lip-service only issue.)
  22.  
  23. Previous to runapp, one wrote a standard main program and linked in a  
  24. standard fashion including a number of ITC and ATK specific libraries. This  
  25. produced a stand-alone executable. Dynamic loading was used primarily for  
  26. extensibility via insets and packages bound to keys. Building an application  
  27. this way involved writing a moderately complex main function and an unwiedly  
  28. Makefile to get the right set of libraries. The main function was  
  29. responsible for specifying which classes were statically loaded and if you  
  30. got this wrong (and there were plenty of ways to do that), your program  
  31. crashed.  Things like the text inset were typically linked into every  
  32. application.
  33.  
  34. As part of the "upside down library" concept, the idea of ATK as a generic  
  35. application also came about and runapp was born. The application and related  
  36. classes were written at this time. (Roughly derrived from the main program  
  37. for ez.) The end result was shared text for all of the core ATK code. Core  
  38. programs that were likely to have multiple simultaneous invocations were  
  39. linked into runnap (namely typescript and ATK).
  40.  
  41. Some years later, many UNIX systems support shared library mechanisms of one  
  42. sort or another. Depending on the particular mechanisms used it may or  
  43. maynot be attractive to use system shared libraries instead of runapp.  
  44. Notably, some systems allow you to share unmodified data pages as well as  
  45. text pages. Unfortunately, the build procedures are likely to be very  
  46. different for each implementation of shared libraries.
  47.  
  48. When measuring such things, the following are of interest:
  49. - Total resident set of the ATK applications you run.
  50. - Startup time for a given ATK application.
  51. - Runtime of ATK applications.
  52. - Disk space used for ATK installation.
  53.  
  54. Resident set was the highest priority for most of the work done at the ITC.  
  55. Saying runapp is only 135k says nothing about the resident set. (On BSD  
  56. systems ps -aux and vmstat are useful for assesing memory usage. However  
  57. doing detailed accounting can get complicated and there were cases where  
  58. none of the standard programs gave the information I needed when I was at  
  59. the ITC.)
  60.  
  61. Finally, the problem of "heinous" memory usage is not unique to ATK. I hear  
  62. many of the same complaints about Macapp on the Macintosh (which is  
  63. approaching simillar size to ATK) and NeXTStep, (Not to mention MS-Windows).  
  64. My conclusion is systems developed with ease of programming of higher  
  65. priority than performance will be resource inefficient. And they are doomed  
  66. to be bitched about by applications developers.
  67. --
  68. Zalman Stern           zalman@adobe.com            (415) 962 3824
  69. Adobe Systems, 1585 Charleston Rd., POB 7900, Mountain View, CA 94039-7900
  70.   "Yeah. Ask 'em if they'll upgrade my shifters too." Bill Watterson
  71.