Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!mips!pacbell.com!pacbell!m5!tma
From: tma@m5.COM (Tim Atkins)
Newsgroups: comp.lang.smalltalk
Subject: Re: Stand-Alone .exe's & C libraries
Message-ID: <4752@m5.COM>
Date: 24 Apr 91 21:12:49 GMT
References: <91104.114417U09762@uicvm.uic.edu> <4321.280dd75f@iccgcc.decnet.ab.com> <2268@media03.UUCP>
Reply-To: tma@m5.UUCP (Tim Atkins)
Organization: Object Sciences Corp., Menlo Park, CA
Lines: 20


	It is pretty obvious to me that using a piece of C code from
Smalltalk will be slower than staying in Smalltalk if certain conditions
are met.  Accessing the C function has a certain amount of set up and
return overhead that varies depending on the flavor of Smalltalk (dll
vs. setjmp/longjmp for instance) and the cost of doing the needed interface
setup on the particular machine.  Obviously, if the relative speed
advantage of the C vs. Smalltalk code is less than the cost of warping
out of Smalltalk to execute the code plus the cost of any needed Smalltalk/C
conversion routines, then the functionality *should be*
written in Smalltalk.  
	This is only a simple quantitative test however. Factors such
as the maintainibility and extensibility of the resultant code sets
must also be considered in relation to the problem domain requirements.
Occassionally it may also make sense to code a functionality in a 
"foreign" language simply because useful information is thereby made
available to the foreign interface layer that will be needed in subsequent
calls.  

- Tim Atkins