From: zstern@adobe.com (Zalman Stern)
Subject: Re: More checks on size of ATK applications
Organization: Adobe Systems Incorporated
Date: Fri, 21 Aug 1992 21:40:54 GMT

Its strange to drop in here every now and then and find out that nothing has  
changed in three or four years...

The original goal of runapp was to use standard UNIX shared text mechanisms  
to simulate shared libraries. (At the time, we referred to this as an  
"upside down" library approach. The original idea was either Andy Palay's or  
Tom Neuendorffer's. I believe it was Mike Kazar who coined the term  
"pinapple upside down library.") This was at about the tail end of the time  
when the ITC was incredibly concerned about memory usage. (Shortly  
thereafter it became a lip-service only issue.)

Previous to runapp, one wrote a standard main program and linked in a  
standard fashion including a number of ITC and ATK specific libraries. This  
produced a stand-alone executable. Dynamic loading was used primarily for  
extensibility via insets and packages bound to keys. Building an application  
this way involved writing a moderately complex main function and an unwiedly  
Makefile to get the right set of libraries. The main function was  
responsible for specifying which classes were statically loaded and if you  
got this wrong (and there were plenty of ways to do that), your program  
crashed.  Things like the text inset were typically linked into every  
application.

As part of the "upside down library" concept, the idea of ATK as a generic  
application also came about and runapp was born. The application and related  
classes were written at this time. (Roughly derrived from the main program  
for ez.) The end result was shared text for all of the core ATK code. Core  
programs that were likely to have multiple simultaneous invocations were  
linked into runnap (namely typescript and ATK).

Some years later, many UNIX systems support shared library mechanisms of one  
sort or another. Depending on the particular mechanisms used it may or  
maynot be attractive to use system shared libraries instead of runapp.  
Notably, some systems allow you to share unmodified data pages as well as  
text pages. Unfortunately, the build procedures are likely to be very  
different for each implementation of shared libraries.

When measuring such things, the following are of interest:
- Total resident set of the ATK applications you run.
- Startup time for a given ATK application.
- Runtime of ATK applications.
- Disk space used for ATK installation.

Resident set was the highest priority for most of the work done at the ITC.  
Saying runapp is only 135k says nothing about the resident set. (On BSD  
systems ps -aux and vmstat are useful for assesing memory usage. However  
doing detailed accounting can get complicated and there were cases where  
none of the standard programs gave the information I needed when I was at  
the ITC.)

Finally, the problem of "heinous" memory usage is not unique to ATK. I hear  
many of the same complaints about Macapp on the Macintosh (which is  
approaching simillar size to ATK) and NeXTStep, (Not to mention MS-Windows).  
My conclusion is systems developed with ease of programming of higher  
priority than performance will be resource inefficient. And they are doomed  
to be bitched about by applications developers.
--
Zalman Stern		   zalman@adobe.com		    (415) 962 3824
Adobe Systems, 1585 Charleston Rd., POB 7900, Mountain View, CA 94039-7900
  "Yeah. Ask 'em if they'll upgrade my shifters too." Bill Watterson