Newsgroups: comp.lang.smalltalk
Path: cantaloupe.srv.cs.cmu.edu!das-news2.harvard.edu!news2.near.net!news.mathworks.com!udel!gatech!swrinde!pipex!bnr.co.uk!corpgate!bcarh189.bnr.ca!nott!cunews!tina.mrco.carleton.ca!knight
From: knight@mrco.carleton.ca (Alan Knight)
Subject: Re: Digitalk... The end...
Message-ID: <knight.793847358@tina.mrco.carleton.ca>
Sender: news@cunews.carleton.ca (News Administrator)
Reply-To: knight@mrco.carleton.ca (Alan Knight)
Organization: Carleton University
References: <knight.793671500@tina.mrco.carleton.ca> <3ir6bb$jlv@news1.delphi.com>
Date: Mon, 27 Feb 1995 01:09:18 GMT
Lines: 56

In <3ir6bb$jlv@news1.delphi.com> jsutherland@BIX.com (Jeff Sutherland) writes:

I wrote:
>> Yes, there
>>are more meaningful benchmarks than Smopstones. These aren't them.

>I think Gartner Group disagrees with you.  They say the overwhelming reason
>for Smalltalk not being more widely used in corporate environments is large
>memory requirements.  Many of their large clients have thousands of PCs
>that they are not ready to upgrade to 24MB of memory.  I don't think we are
>the only vendor that is working hard to reduce the memory requirements for
>Smalltalk.  Memory issues have more performance impact than garbage
>collection on 95% or more of the installed base of corporate PCs.

Memory footprint is certainly important. I should point out, however,
that there exists a commercial Smalltalk which has been widely used
for products, and which can easily deliver applications which run in
8MB, 4MB if you're willing to work at it. That Smalltalk is Digitalk's
V/Win16. If memory requirements are the overwhelming reason, then they
should all just switch to that. It's cheap, too. OK, so it's missing
lots of features, and it doesn't have very good performance. Its
performance is still much better than Easel, even on machines where
they both have adequate memory. Run the tests on a 4MB machine and
Digitalk will blow you away.

Don't forget that the 24MB is for the full development environment.
IBM has an extremely sophisticated packager for producing run-time
versions. It has been used to produce some very compact applications
(e.g. embedded systems).

I would certainly expect memory issues to be larger than garbage
collection. I would expect that for most applications the performance
cost of garbage collection is negative. (i.e. I think garbage
collection improves performance over not having it for most
non-trivial programs). I certainly expect garbage collection to be
irrelevant as compared to a basic execution engine that is several
times slower.

In any case, if you wish to compare memory footprint, try saying
something like.

    "We think memory footprint is a very important issue. For a simple
application, our footprint is <development>/<runtime>, whereas
competitor X's, is <development>/<runtime>. Beyond these levels,
applications start to experience significant swapping overhead"

This is considerably more meaningful than citing figures about
execution speed that are 90+% swapping overhead, and which will vary
by orders of magnitude with small variations in the machines they are
run on.

-- 
 Alan Knight                | The Object People
 knight@acm.org             | Smalltalk and OO Training and Consulting
 alan_knight@mindlink.bc.ca | 509-885 Meadowlands Dr.
 +1 613 225 8812            | Ottawa, Canada, K2C 3N2
