Newsgroups: comp.lang.smalltalk
Path: cantaloupe.srv.cs.cmu.edu!bb3.andrew.cmu.edu!newsfeed.pitt.edu!scramble.lm.com!news.math.psu.edu!news.cse.psu.edu!uwm.edu!spool.mu.edu!howland.reston.ans.net!swrinde!newsfeed.internetmci.com!ncar!newsxfer.itd.umich.edu!qiclab.scn.rain.com!gemstone.com!servio!servio!aland
From: aland@servio.slc.com (Alan Darlington)
Subject: Re: Efficient Smalltalk
Message-ID: <1996Jul29.221840.12252@gemstone.com>
Sender: news@gemstone.com (USENET News)
Nntp-Posting-Host: servio
Organization: GemStone Systems, Inc., Beaverton OR, USA
References: <4tall2$p4q@redstone.interpath.net> <4tb9i7$gt0@vnetnews.value.net>
Date: Mon, 29 Jul 1996 22:18:40 GMT
Lines: 32

adonis@value.net (Adonis Ioannou) writes:
> davjen@usairln.usair.com wrote:
> >I wonder if I could prevail upon the wisdom of the Smalltalk experts who read this newgroup
> >to suggest ways to improve the efficiency of Smalltalk applications.  I'm asking because I'll
> >soon become responsible (along with two other neophyte Smalltalkers) for maintaining and enhancing
> >an OS/2 application another department in our company wrote in VisualWorks.  I recently saw
> >the application demonstrated, and although it has many many virtues, the users complained that
> >the application's response over the course of the day grows slower and slower, until finally
> >they find they must reboot and reload the application to use it practically.  The department
> >that wrote the application is working on a fix, which may in the end have nothing to do with
> >Smalltalk at all, but the experience made me realize that I know little about the mechanics
> >of Smalltalk applications, how to determine their efficiency (or lack thereof), etc.  Can anyone
> >point me in the direction of a book or article(s) on the topic?  I'd be most grateful.
> 
> A good place to start, is to use a Profiler tool. I think this is part
> of an Advanced set of disks in VisualWorks, or you can always ask
> Parcplace to see where you can get one. A good profiler would give you
> info about the number of times a given method executes and how long it
> takes. Based on that info, you can make some changes in the code.
<snip>

Another thing to do is check your memory usage.  It is quite common for
applications to keep unnecessary and/or obsolete objects around, which
increases memory requirements and usually degrades performance at the
OS level (i.e. page thrashing).  If you have frequently-used and/or
large objects, check to see how many instances exist at intervals over
a long period of time.  An increasing number is a sign of possible
trouble.  The dependants mechanism is another area that often causes
objects not to be garbage collected.

  Cheers,
  Alan
