Path: utzoo!attcan!uunet!munnari.oz.au!metro!ipso!runxtsa!timm
From: timm@runxtsa.runx.oz.au (Tim Menzies)
Newsgroups: comp.object
Subject: Re: Smalltalk performance
Message-ID: <2527@runxtsa.runx.oz.au>
Date: 4 Nov 90 20:26:24 GMT
References: <1990Oct19.220747.5536@Neon.Stanford.EDU> <ARO.90Oct24150357@raphael.cs.aber.ac.uk> <1461@media01.UUCP>
Distribution: eunet,world
Organization: RUNX Unix Timeshare.  Sydney, Australia.
Lines: 58

My remarks re smalltalk performance relate to Smalltalk/V and V286
running on 286 and 386 PS-2/ ATs/ Compaqs.

0)	I've never not  done  things in smalltalk  due to speed issues.
	I usually say that brain  beats brawn. Yes, it goes faster on  a 
	Cray, but  a little thinking can go a long  way  to speeding  
	up a system.
1)	The  interface speed is impressive. The limiting factor  on its
	performance  is usually how  fast i  can  move a mouse around.
2)	The  speed of the internal code is  good, but. I usually tell
	people that its fast to do thousands of  things in Smalltalk,
	ok to do tens of thousands of things, and slow to do  hundreds
	of  thousands of things.For example:

	Time millisecondsToRun: [30000 timesRepeat: [true]]

	takes a non-trivial amount of time. So, the thing that Smalltalk
	should be best at (simulation) is  ironically the thing that it
	is worst at. I  tell people that if there  is some  massively
	computationally expensive process to be run, write it in "C"
	compile it to assembler, and  load it into the  smalltalk
	environment using:

		Smalltalk loadPrimitives:  'foo.bin'.

3)	Smalltalk/V goes very slow when its memory is full, just  prior 
	to a  disk  swap. Haven't had a swap  yet in  V286. The 
	following  code returns the amount of memory free. Its a good
	idea  to monitor this number.

		Smalltalk  unUsedMemory
	
	One trick I've found, is  to leave strings on  disc. Instead
	of loading  lots and lots  and lots  of text, leave it in a  disc
	file and store internally:

		textStart, textStop.

	The method  "File position: textStart" works  very fast.  I've
	accessed a string  in a four megabyte file in 60ms (not bad,
	considering that the latentcy time on that drive was 30ms).
4)	Compaqs are faster than IBMs. The disc swaps on a Comapq  are 
	about twice  as fast  as on an IBM.
5)	And on a final  note: multi-tasking  under V286  is surprisingly
	fast. Recently I wrote an "autosave" utility that forks  a 
	process at lowest priority that loops infinitely and saves the
	image every twenty minutes. I was a  bit reluctant to do this at
	first since I thought it would slow  every else down. I've been
	running the thing now constantly for  four  days while I  do my 
	development work  and I haven't  noticed a slow down (or,
	surprise surprise,a nd idiosyncratic time-dependant processing
	errors).

--
 _--_|\  Tim Menzies (timm@runxtsa.oz)        "Its amazing how much 'mature
/      \ HiSoft Expert Systems Group,          wisdom' resembles being too
\_.--._/ 2-6 Orion Rd Lane Cove, NSW, 2d066    tired." - Lazarus Long
      v  02 9297729(voice),61 2 4280200(fax)             (a.k.a. Bob Heinlein)