From: peterg@netcom.com (Peter Goodall)
Subject: Re: comparing object-oriented platforms
Organization: Netcom - Online Communication Services  (408 241-9760 guest) 
Date: Sat, 3 Oct 1992 04:58:01 GMT

88600044s@csghsg5a.bitnet writes:

>In previous postings it has been said that Smalltalk is
>both slow and too big. I agree that the file of the final
>executable can be much bigger than appropriate. Now there
>is Envy/Developper that steps through all of your code of
>your application and removes all code from the image that 
>is not needed in your application. This process can take
>over a night to finish but the result is a minimum possible
>executable file.

The feature of ENVY refered to is the ENVY/Packager, which given a set of
rules and a fair ammount of understanding produces a new, separate image. I
the case of /VPM a new set of base DLLS, replacing the All but the VM and
Float emulator of the original Digitalk set. On a '486 with 16MB we convert
a 5 MB development image into a 3.8 Mb runtime system.

One useful side-effect is that because the packager starts from the VM
messages and does a transitive closure of potential message sends within
the Applications (Envy software modules) marked to be included. A lot of
quality control on unimplemented and unexercised code is done. Every symbol
that could be sent as a message is expected to have an associated
implemented method. You get to see a lot of trash. Of course it shouldn't
be there ;-)

>Second, there is Smalltalk/V PM v2.0 waiting. It will be
>truly 32-bit and therefore also significantly faster. It
>will also be truly multi-threaded (v1.4 does only have two
>threads: a background and a foreground one).

>Nevertheless, I agree that a Smalltalk app is not that fast
>as one written in C/C++. But now with Envy/Developper and
>SMalltalk/V PM v2.0 think oops tings aren't that easily as
>before. Smalltalk does have catched up as what speed is concerned.
>If I had to write Lotus 1-2-3 (of which I m not capable of)
>I would do it in C/C++ (or in Eiffel if a usable system
>were existing), but for in-house applicatins there is no 
>better thing than Smalltalk.

**** Rave On ****
Most of the performance and size problems I've seen are design problems.
The most common design problem is lack of a design, the second most common
is working against Smalltalk rather than with it. For example writing
'case' statements that ask arguments their class and dispatch a method on
the condition.

	(arg isKindOf: aClass)
		ifTrue:[ ^arg doSomething ].

	(arg isKindOf: anotherClass)
		ifTrue:[ arg doSomethingAlmostTheSame ].

	... ad infinitum

the thing that the new Smalltalk programmer misses is that arg already
knows its class, and is built to #doSomething appropriate when told to.

I have seen people slow systems by 50%+ by doing this stuff.  In just one
place!

That problem is more of technique than design. The real killer is, as I
cheekily said at Momenta, 'Unfortunately, due to the robustness of the
develoment environment, the system kept running.' 

Smalltalk is so robust that systems are often dead, but they won't lie
down. 'Design' by attaching special case behavior makes big ugly slow
incomprehensible systems. If you start adding special cae code to the
system. Stop, and think what was wrong with the system mode that a special
case was needed. Tear the system down and rebuild it to be consistent.
Often.

**** Rave Off ****

Thanks,

Peter Goodall -- peterg@netcom.com
Xref: sparky comp.lang.smalltalk:1952 comp.lang.eiffel:1180 comp.object:3758