Prolog

Problem

Forces

Early in development is when you should be listening carefully to the users needs and taking stock of your available resources. If every thought is poisoned by "Yes, but how fast will that run," you will likely miss the chance to make large leaps in development.

At the same time, performance is a legitimate concern. If the program doesn’t go fast enough, you will not if fact get paid (or keep getting paid). You need to assure yourself and your client that performance problems will not sink an otherwise brilliantly crafted and executed system. Therefore:

Solution

Discussion

Hard real time systems have a long history of careful performance assessments. When you know you have to service an interrupt in 10 microseconds, well, that pretty much shapes at least one major subsystem. Most systems, although often called real time, are not nearly so restrictive.

Areas that may require a prototype might be any unique area of your system that you deem somewhat complex and whose responsiveness is critical to the success of your application. For example, you may have a map that needs to display hundreds of small labels and icons representing particular locations. Throw together a prototype that pumps hundreds of random labels and icons to the screen in random spots. If it’s too slow, figure out what’s taking all the time and tune the prototype. When you are convinced it can be done (or can’t), throw out the prototype and start the real work (or revise your expectations)

Epilog

Prolog

Problem

Forces

Some programs spend considerable time in Smalltalk. These programs will be efficient to the degree they leverage but do not stress Smalltalk resources such as message sending and the garbage collector.

Other programs are limited by resources out of the direct control of the programming language- virtual memory, database access, graphics calls, etc. Another standard of efficiency is how effectively a program uses the resources, how short the path is from a stimulus from the outside world to a stimulus for the outside world.

Almost every professional programmer has had the experience of writing a program, taking heat because it is too slow, and (importantly) not being able to fix the performance problems in a timely fashion. Some programmers react to this rite of passage by insisting that performance is a legitimate concern throughout development. No request for functionality or proposal for design refinement can be considered until it has past the "can it run fast" test.

This practice is the death of effective development. Progress slows to a crawl as every thought is forced to pass through the sieve of fear. Decisions are optimized for presumed performance impact rather than short or long term programming productivity and low risk. The result is large programs with limited functionality. They grow progressively more and more complex until they cease being valuable to the developing organization.

The irony is that such programs are virtually impossible to keep running fast. Their lack of clarity robs you of the ability to identify performance bottlenecks. Even if you could find a problem, chances are you could not address it without making widespread changes, exactly the sort of activity you must avoid late in development.

So, you have to worry about performance or your users won’t be satisfied, but it doesn’t help to worry about it all the time. Therefore:

Solution

Discussion

Not only will this strategy give you actual time to do the necessary optimization, but also it will appease early viewers of your program who deem it too slow. You can always say, "yes we know it is too slow. You can see where, in our project plan, we plan on addressing this issue." Of course, if you don’t give yourself enough time to actually do the tuning, your still going to look bad. One rule of thumb is to assume 35% of the development time will be required for tuning for those inexperienced at the process of tuning in Smalltalk, decreasing to 10% for experienced developers.

Epilog

Prolog

Problem

Forces

Many parts of your system will work without any complaints about performance even if they are implemented the simplest possible way. In addition, you cannot be sure in advance where performance bottlenecks will lie^[Barry91]. You can’t even be sure which bottlenecks will bother users and which won’t. Therefore:

Solution

Discussion

• Interactive response time
• Frame rate
• Bits per second
• Transactions per second

As time goes on, your client (or you) may notice new things that just are not snappy enough. Make sure the particular complaints are specific and goals are explicitly stated.

Epilog

Prolog

Problem

Forces

Programs that are to be used by people are both constrained by and can take advantage of the quirks of human perception. In particular, actual performance and perceived performance are not linearly related.

Once you get past a perceptual threshold, substantial further measured performance improvement will result in little or no perceived improvement. Therefore:

Solution

Discussion

Epilog

Prolog

Problem

Forces

If you have a good list of efficiency hacks, e.g. "when you see A, do B instead", you could look for all occurences of the "slow" ways of doing things (e.g. As) and replace them with their faster counterparts (Bs). Odds are good you'll end up with a much faster program, but it will take an awful long time to find all of the potentially slow things you've done. Also, there may be so many places you have to change, you might wonder why you didn't just write your code like that in the first place. Then you'll look at the probably unreadable result and remember why. Chances are you will have replaced a lot of code that ran "fast enough" if you just left it alone.

Even if you've done this exhaustive search and destroy, you may have missed some bottlenecks that were not in your catalog of efficiency tricks. You might even have missed the one or two key bottlenecks that, if corrected first, would have made all the other efficiency hacks unnecessary. Therefore:

Solution

Discussion

In a last ditch effort to figure out whether their work could be salvaged, Dave Leibs, Smalltalk performance guru from ParcPlace Systems, Inc. was called in for a day of consulting. They quickly described an overview of what they were trying to do. Nothing stood out to Dave as anything that would bring Smalltalk to its knees. So, he said,

"Where did the Profiler indicate most of the time was being spent?"

"What’s the Profiler?"

So he spent the next 30 minutes or so explaining what the Profiler was and helping them install it.

He then ran the profiler on the section of code in question and found it was spending more than 98% of it’s time in Date>>printOn:. Dave thought for a second what might be so slow about Date>>printOn: and felt it should not cause so great a problem. So, he looked a little higher up the profile tree and examined the containing method.

He noticed the expression ‘Date today printString’ inside of a loop. So he chose an Experiment and pulled the expression out of the loop, storing the value in a temporary variable which he then used inside the loop. Ten minutes after running the Profiler for the first time, he ran the code again. This critical section of code that was central to the client’s system now took less than a second.

Dave then turned to his hosts and said, "So, what are we going to do for the rest of the day?"

Epilog

Prolog

Problem

Forces

However, dividing the work this way takes away the collaborative effort of individuals and the benefit of finding commonality of problems.

On the other hand, if you have everybody standing around analyzing the best way to go about solving the problems, they won't ever get addressed.

Solution

Discussion

Epilog

Prolog

Problem

Forces

However, we must remember the points made in Threshold Switch with respect to efficiency hacks sacrificing later maintainability. Therefore:

Solution

Discussion

Not only is the new printOn: method not worth leaving it in now for performance reasons, but also think about future ramifications of leaving it in. Some poor maintenance programmer comes along with the thankless job of upgrading the system to the next release of VisualWorks. He first tries to find out all of the base image changes his company has made that need to be carried forward. He discovers this change (which may or may not have a comment explaining what was done to it). He also notices that the new version of VisualWorks has a different version of the method than the previous version (before the hacked change). People will start noticing the amount of time trying to figure out what to do here more than they ever noticed the 0.01 seconds it bought them in the first release of the product.

Epilog

Prolog

Problem

Forces

On the other hand, the result of an expression takes up memory somewhere (e.g. the execution stack) no matter what. We shouldn’t get too carried away with the avoidance of memory usage.

Solution

Discussion

After a redesign of a prototype (Concise Design), performance had improved significantly (3-5x) without performance being a primary goal. However, this performance was still deemed unacceptable. Performance Criteria were established.

In a period of one week, system response time was improved roughly one order of magnitude.^[White91] Due to the Concise Design there was little to overhaul. Most of these performance improvements were due to finding common expressions and speeding them up by Caching Expressions.

On the other hand, keeping may force other methods to be aware of caches. For example if a Rectangle caches its area in an instance variable, all methods that allow changes to the Rectangle’s coordinates must do something to make sure the cached area is reset.

Caching variables can also threaten the integrity of the object containing the cache itself. For example, before the area cached instance variable is added, the following expression (although bad practice) would not threaten the integrity of the object:

aRectangle origin y: 25

The implementor of Rectangle chose to take the risk of exposing it’s instance variable for a variety of reasons knowing that, as the implementation stood, such an expression as this would not break anything.

As soon as the Cached Instance Variable is added, such an expression would result in a problem as there would be no way to trigger a cache reset without additional mechanisms.

Epilog

Prolog

Problem

Forces

Often seemingly harmless expressions inside a loop return the same result each time

Solution

Discussion

collectColumns: anArrayOfColumnNames
^self rows collect:
[:row |
anArrayOfColumnNames collect: [:name | row at: (self columnIndexFor: name)]]
columnIndexFor: aColumnName
^self columnNameMaps at: aColumnName

Realizing the column indices of interest are going to be the same each time through the loop, you could greatly reduce the amount of times #columnIndexFor: is sent as follows:

collectColumns: anArrayOfColumnNames
| columnIndices |
columnIndices := anArrayOfColumnNames collect: [:name | self columnIndexFor: name].
^self rows collect:
[:row |
columnIndices collect: [:index | row at: index]]

Epilog

Prolog

Problem

Forces

Solution

Discussion

printList
| list |
self isEmpty ifTrue: [^String new].
list := self first printString.
2 to: self size do:
[:index |
list := list, ', ', (self at: index) printString].
^list

Objects convert themselves into strings by creating a Stream on an empty string and sending themselves the printOn: message with the Stream as an argument. We could instead create a single Stream which all objects would write to.

printList
| stream |
stream := WriteStream on: String new.
self do:
[:each |
each printOn: stream.
stream nextPutAll: ', '].
self isEmpty ifFalse: [stream skip: -2].
^stream contents

Another example would be to pass a collection into which all objects which had something to contribute would add to.

allFemaleChildren := Set new.
self people do: [:each | each addFemaleChildrenInto: allFemaleChildren]

The addFemaleChildrenInto: method would do nothing but add to the passed collection, or do nothing if there are no female children. It could be used instead of:

allFemaleChildren := Set new.
self people do: [:each | allFemaleChildren addAll: each allFemaleChildren]

which would create an intermediate collection, maybe even an empty one.

Epilog

Prolog

Problem

Forces

However, sometimes, ignoring the implied side-effects of an operation is exactly what causes performance problems. Everything must be calculated dynamically because "you never can be sure" whether the environment has changed since the last time the result of the expression was needed.

In the context of a single method, or a chain of methods, knowledge of a local environment (temps, arguments, etc.) can be exploited via Caching Temporary Variables or Caching Arguments. The decisions to use these types of Cacheable Expressions affect no one else but the execution stack which is pretty well secure from the rest of the system. Unfortunately, the system encompasses much more than this local environment and such techniques can not solve all performance problems.

Yet, we still want to avoid caching expressions at a level that exposes the cache to the entire system, and therefore limits design possibilies and exposes integrity problems on a wide scale. For instance, if we kept the results of an expression for anyone to use in a global variable all methods that wanted to benefit from the results of the cache would have to know about its existence by name. Additionally, any actions anywhere in the system that would invalidate its value would have to explicitly reset it.

You would like to encapsulate the Cacheable Expression in as low a level as possible that will affect all of the contexts which would like to exploit the cache. Classes, MetaClasses, and Class hierarchies each define an environment narrower than the system level but broader than the execution stack. Each define their own behavioral environment. Therefore:

Solution

Discussion

dot
^"build the icon"

Realizing the icon will be the same for all instances of all classes in the hierarchy:

dot
Dot == nil
ifTrue: [Dot := self computeDot].
^Dot

If the dot size needed to change based on user preferences changing, a hook would have to be inserted to flush the Dot whenever the user preferences changed.

Similarly, an instance method

fullName
^last, ', ', first, ' ', middle

could become

computeFullName
^last, ', ', first, ' ', middle
fullName
fullName == nil
ifTrue: [fullName := self computeFullName].
^fullName

and methods that set the parts of the fullName would be modified to reset the fullName as the example below shows:

last: aString
last := aString.
self fullName: nil.

If you needed an icon to represent the on state for a particular class of button, but the icons were different for different classes of buttons in the hierarchy, you could implement:

onIcon
^"build the icon"

Realizing the icon will be the same for all instances of all classes in the hierarchy:

• onIcon
  ^self class onIcon

class>>onIcon
onIcon == nil
ifTrue: [onIcon := "build the icon"].
^onIcon

Clearing the cache of class instance variables may require some awkward code in the root class to ensure that all caches are cleared simultaneously:

class>>resetClassCache
self withAllSubclassesDo: [:each | each cacheVar: nil].

Epilog

Prolog

Problem

Forces

Case statements could be inserted to detect a particular context. However, such statements are ugly and often slow down execution for the more general cases due to the overhead of case checking. Therefore:

Solution

Discussion

Arrays are generally more efficient than OrderedCollections. They take up less space, don’t have extra instance variables to manager to denote the beginning and end of collection, and avoid a level of indirection in accessing their indexed instance variables.

Symbols, once created, are much faster to compare than Strings as they are merely comparing object pointers as opposed to comparing each individual element contained by the String.

Additionally, one can often create classes that are simplifications of more flexible classes if that flexibility is not needed. For example, ComposedText in VisualWorks will handle various composition features of text (word-wrapping, tabs, changes of fonts, etc.). If you simply want to display a simple ASCII String in a single font with no special characters or composition considerations, one could create a simple class, such as VisualString which simply calls the primitive for displaying a string using the particular font without any intermediate effort.

Epilog

Prolog

Problem

Forces

Ah, but their dirty little secret is they don't like going unnoticed, so they leave their mark by gobbling up CPU cycles. Creation here, a few messages sent there, a little garbage collection to clean up the mess and eventually someone might notice that more time has gone by than they had planned.

Solution

Discussion

Epilog

Prolog

Problem

Forces

Preserving encapsulation.

Solution

Discussion

moveBy: aPoint
origin := origin + aPoint.
corner := corner + aPoint.

which results in the old Rectangle being transformed to the new, creating one less object and adding one less object to the garbage heap. If one really wanted to throw caution to the wind, and was sure the original Rectangle was the only object referring to the Points held by its origin and corner variables. One could write a method (and send the corresponding message) that reused the same Points and therefore created no new objects nor added any objects to the garbage heap. E.g.

transformBy: aPoint
origin x: origin x + aPoint x.
origin y: origin y + aPoint y.
corner x: corner x + aPoint x.
corner y: corner y + aPoint y

Epilog

Prolog

Problem

Forces

When adding many objects to a relatively small collection, much of the time is spent growing incrementally larger buffers and copying objects from the old to the new buffer.

Solution

Discussion

nonBaseClasses
| collection |
collection := Set new.
Smalltalk allClassesDo:
[:each |
each superclass == nil
ifFalse: [collection add: each]].
^collection

allocate enough space in the collection to avoid growth:

nonBaseClasses
| collection |
collection := Set new: Smalltalk classNames size.
Smalltalk allClassesDo:
[:each |
each superclass == nil
ifFalse: [collection add: each]].
^collection

Epilog

Prolog

Problem

Forces

Streams provide a way out of this dilemma. Streams are careful not to copy their contents many times.

Solution

Discussion

100 timesRepeat:
[result := String new.
1000 timesRepeat: [result := result , 'abcdefg']]

It took 53 seconds to run. Then we ran the Stream version:

100 timesRepeat:
[writer := WriteStream on: String new.
1000 timesRepeat: [writer nextPutAll: 'abcdefg'].
writer contents]]

It took 0.9 seconds to run. The difference is a factor of almost 60.

Sometimes you will use Concatenating Stream not because it is your choice, but because you have to fit into other code that already uses it. The most common example is specializing object printing by overriding printOn:.

Note that this pattern can also be combined with Hypoth-a-sized Collection to create a Stream whose collection can avoid growing.

Epilog

Go Back