If you use the standard configuration out of the box, you will probably run into some difficulty when your object model starts to grow. Luckily Smalltalk MT has many configuration options to allow you to build big and fast Object models.
My first large model experience was in loading up all of the stock options from the stock market (some 174,000 options at any one time). I had built a Dictionary containing the Option symbol and an Option object. I ran into a problem with trying to inspect the Dictionary. I thought that STMT had hung because it was taking so long.
So I tried a test:
| dict := StringDictionary new: 170000. Time millisecondsToRun: [ 1 to: 170000 do: [:index| dict at: 'Key',index asString put: index ] ]. |
This portion of code executes in about 6 seconds on my machine. But then try:
Time millisecondsToRun: [dict inspect].
This runs for a very long time (approx 11 minutes) far longer than I had expected. Looking at the Smalltalk inspect code did not reveal any culprit. The only two possible performance areas were Garbage collection or something in Windows. The culprit turned out to be the Listbox.
The Windows Listbox handles a limited number of items very well, but it struggles when the list becomes excessive. When working with large Object Models one often needs to to look at large collections and the standard inspector which uses a ListBox is not adequate. For a solution, see the Virtual List Box tutorial.
Now that we have a tool for inspecting large collections, let us move on to a serious test.
We are going to try some code in a workspace that will potentially cause your image to hang. Please make sure all you work is saved before trying this test. I am going to assume here that your development environment is as it was released to you. This is, in the Image Properties (from the Transcript Tools menu) Process tab in the Smalltalk Memory Settings box the Heap Reserve is set to 30Mb.
Let us try the VirtualListBox on 1000000 items! First we need to create a collection with 1M items.
I left this running for at least 1/2 hour and I could not get this to finish. So I killed the image and this time started the performance monitor (available in both Windows NT and Windows 2000) running before executing the test. If you select Performance Object Thread, you should see 5 threads (STIMAGE/0 through STIMAGE/4) representing the running Smalltalk MT process. If you see less than this try Transcript File menu Open... and open a file. Now run our test again and you will see that two threads are competing for processor time. As one diminishes, the other increases and vice versa. This is a classic garbage collection problem. Every time the main thread (STIMAGE/0) allocates, the garbage collector has to garbage collect and this is taking up some 20% of the time.
The solution is to allocate more memory so that more objects can be allocated before the garbage collector steps in. Go to the Image Properties Process tab and change the Heap Reserve in the Smalltalk Memory Settings box to 250. The test above now runs in about 10 seconds.
Now we can really test the Virtual List Box. Timing 'VirtualListWindow openOn: oc' returns 18 milliseconds to open on the 1000000 items.