Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!swrinde!elroy.jpl.nasa.gov!decwrl!ucbvax!bloom-beacon!eru!hagbard!sunic!mcsun!hp4nl!media03!pkr
From: pkr@media03.UUCP (Peter Kriens)
Newsgroups: comp.lang.smalltalk
Subject: Re: Stand-Alone .exe's & C libraries
Message-ID: <2268@media03.UUCP>
Date: 19 Apr 91 08:04:02 GMT
References: <91104.114417U09762@uicvm.uic.edu> <4321.280dd75f@iccgcc.decnet.ab.com>
Reply-To: pkr@media03.UUCP (Peter Kriens)
Organization: aQute, Netherlands
Lines: 34


 klimas@iccgcc.decnet.ab.com writes:
        be <64kb in size.  Another reality that drives C fanatics crazy
        is that there is not much to be gained by using C based functions
        in terms of speed or memory.  We have actually seen a reduction
        in total program size when we rewrote some C based libraries in
        Smalltalk/V-286 and the performance was just the same if not faster.

I happen to be a Smalltalk fanatic but I am having problems with this
statement. I love Smalltalk for its expressiveness and power, but I hate it
for it's speed. And writing some heavily used parts in C can speed it up. Try
writing he V286 floating point package in Smalltalk. I think that you should
differentiate between different problems. Smalltalk handles C code as
primitives and I think we should regard them as such. Pieces of code that
do one thing very good and very fast. In hypercard on the macintosh there is
a very similair very populait facility to extend hypercard (ver, very necessary)
called XCMD's. There is a lot of public domain code out there so there is
a good insight in how people are coding them. What you usually see that they
handle much too much in their primitives. This will force duplication of
code in the primary and the secondary environment and usually also in loss
of speed.

But if you make primitives in the right way, they can speed up you application
and make things possible which are impossibale in Smalltalk, like controlling
or monitoring external devices, fast fourier transform (try that in Smalltalk).

As said earlier, I love Smalltalk, but I think we must remain honest about
it's major drawback: speed.

By the way, I am very interested in an example of coupling C code to Smalltalk
and than loosing speed. Could you elaborate a little bit more on that?

Peter Kriens
pkr@media01.uucp