Path: utzoo!attcan!uunet!jarthur!elroy.jpl.nasa.gov!sdd.hp.com!zaphod.mps.ohio-state.edu!samsung!crackers!m2c!umvlsi!dime!dime.cs.umass.edu!moss From: moss@cs.umass.edu (Eliot Moss) Newsgroups: comp.object Subject: Re: Performance of Smalltalk vs C (or C++) Message-ID: Date: 31 Jan 91 13:32:30 GMT References: <1991Jan4.004138.7013@ashtate> <22574@well.sf.ca.us> <2961.279ffcba@iccgcc.decnet.ab.com> <3282@sequent.cs.qmw.ac.uk> <2995.27a59704@iccgcc.decnet.ab.com> Sender: news@dime.cs.umass.edu Reply-To: moss@cs.umass.edu Organization: Dept of Comp and Info Sci, Univ of Mass (Amherst) Lines: 22 In-reply-to: tom@ssd.csd.harris.com's message of 30 Jan 91 12:08:44 GMT Many more modern Smalltalk implementations, following Ungar's lead, have eliminated the object table and its consequent level of indirection. I would say that there are two primary sources of slowdown compared with C: the examination and manipulation of tags on everything, including small integers, and the overhead of interpretation (which the translation scheme of PARC Place Smalltalk largely avoids). Smalltalk also always error checks -- overflow, array subscripts, types of things in primitives, etc., and these checks have a noticeable run-time impact (Ralph Johnson at Univ of Ill., among others, has research projects that aim to optimize a lot of that away; see also the work done by Ungar and Chambers at Stanford for the Self language). A well designed garbage collector adds less than 10% overhead to what is there, so that is more of a secondary factor, but will become a large fraction as other things get tuned or optimized away. Hope this helps folks understand why Smalltalk "costs" -- a lot of it is safety and flexibility features. -- J. Eliot B. Moss, Assistant Professor Department of Computer and Information Science Lederle Graduate Research Center University of Massachusetts Amherst, MA 01003 (413) 545-4206, 545-1249 (fax); Moss@cs.umass.edu