Path: utzoo!attcan!uunet!wuarchive!cs.utexas.edu!sun-barr!olivea!mintaka!bloom-beacon!eru!hagbard!sunic!mcsun!hp4nl!media01!pkr From: pkr@media01.UUCP (Peter Kriens) Newsgroups: comp.object Subject: Re: Smalltalk performance Message-ID: <1461@media01.UUCP> Date: 25 Oct 90 09:07:29 GMT References: <1990Oct9.190813.23402@ux1.cso.uiuc.edu> <2444@runxtsa.runx.oz.au> <1990Oct19.180646.8649@ux1.cso.uiuc.edu> <1990Oct19.220747.5536@Neon.Stanford.EDU> Reply-To: pkr@media01.UUCP (Peter Kriens) Distribution: eunet,world Organization: Mediasystemen, Netherlands Lines: 33 We have been building a number of applications in Smalltalk that involve mostly user interface processing. Though we sometimes would like to have a more direct responding screen sometimes, (we are running Smalltalk V286, VGA and 386 SX), the overall performance is really very good. Speed problems occur mostly when we try do "massive" processing. For example, we have written a multiuser database in Smalltalk, that works very nice for searches and stores, but when we have to walk along all records, it becomes slow. What I am trying to say that "running code", cq code which does an awfull lot of different things and reacts to the user is perfect in Smalltalk. But the moment you start to handle thousands of "objects", the overhead becomes sometimes prohibitive. On the other hand, the first version of one of our programs took over 45 minutes to make a certain report. Just by using better hardware and going from V86 to v286 we have brought this time back to 10 minutes. Don't be fooled by claims that the overhead of Smalltalk is only 30 percent. This overhead counts only for the comparison between a message send and a procedure call. The difference between C and Smalltalk is that in Smalltalk, each line is one or more message sends, in C a lot of statements are directly expanded to op-codes. Even though we realize that the overhead is there, we have found that the increasing hardware speed allows us to develop a LOT faster and make much more stable code which also usually looks a lot nicer. Peter Kriens hp4nl!media01!pkr