Newsgroups: comp.lang.smalltalk
Path: cantaloupe.srv.cs.cmu.edu!nntp.club.cc.cmu.edu!newsfeed.pitt.edu!gatech!howland.reston.ans.net!xlink.net!news.ppp.de!news.Hanse.DE!wavehh.hanse.de!cracauer
From: cracauer@wavehh.hanse.de (Martin Cracauer)
Subject: Re: smalltalk performance in data intensive application
Message-ID: <1995Jan5.084600.16688@wavehh.hanse.de>
Organization: The poor LISPers' hacking kitchen
References: <carlmD0485s.4n6@netcom.com>
Date: Thu, 5 Jan 95 08:46:00 GMT
Lines: 55

carlm@netcom.com (Carl Margolis) writes:

>My situation is this:
>        I have been charged by my corporate taskmasters with building a 
>Query/EIS/DSS/etc. tool in no time for no money for sale to their current 
>client list which includes Disney's, Macy's, Sears, and other large retailers. 
>Their current transactional systems are all mainframe based. I have been 
>programming in ASM/C/C++ for 14 years. I have a team of 3-4 programmers with 
>1-4 years experience. I'm strongly considering going to smalltalk for this 
>project but I'm worried about smalltalk's performance in applications which 
>require intensive data manipulation of very large data sets. In particular, 
>the kind of multi-dimensional data cube manipulation ("slicing & dicing",etc) 
>have got me worried. I find it hard to believe that a link-list or b-tree 
>collection will provide near the performance I can get out of C/C++. 

You should expect Smalltalk to be significant slower when it comes to
iterate over large collections of low-level data-types, for example
arrays of floating point.

You may be interested in the last issue of the Smalltalk report, where
some optimizations of Smalltalk compilers are discussed. If your
application requires computations that are not covered by the
compilers optimizations, the performance will drop to fraction of
C/C++'s.

The speed of manipulating abstract data types provided by an extern
database or such depends more on programming experience both in C/C++
and Smalltalk. That means, you should get acceptable performance in
Smalltalk when and only when you've got experience in it.
Additionally, different compilers will make a big difference for
certain kinds of appications.

I'd bet your first projects in Smalltalk will be *very*
inefficient. So, if this particular project really requires good
performance, you should stay with a language you are used to.

You posting didn't make clear if you have to process low-level types
much. And you didn't say exactly why you think Smalltalk could be a
better language for this project or what it is you don't like in
C++. If you need C-like low-level type handling combined with dynamic
typing and don't care for full OO programming, Objective-C may be an
option.

>I know I 
>can build a hybrid system but this is not nearly as re-usuable or maintainable.

Smalltalk's foreign function call interface is not very nice (can't
be) and you should use it only to interface to services you cannot
access otherwise. Use it for interfacing, not for processing.

[...]

Martin
-- 
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
Martin Cracauer <cracauer@wavehh.hanse.de> Fax +49 40 522 85 36
