Daniel Salama wrote:

> David,
>
> I executed the following:
> [snip]
>
> The time was 204.789 seconds (about 3 seconds longer than before).
>
I'm surprised that using a BTree didn't improve performance.  The
Dictionary class is basically a Hashtable so all of the items are stored
as associations in an array.  I haven't looked at the GOODS client but I
assume that arrays have to be loaded/commited in their entirety (or
maybe they are paged?).  A BTree is, well, more of a tree structure.  An
insert is likely to only affect one or two nodes of the tree so the
GOODS traffic should be a lot less on each commit.  It might be that
your key choices are problematic for BTree's (causing lots of
splitting?) but I'll reserve further conjecture until I look at it in
detail.

Have you profiled this code?  You can do this with:

TimeProfileBrowser onBlock: ["the block which you are currently passing
to millisecondsToRun:"]

or to produce a simple text output:

MessageTally spyOn: ["the block"]

I'm curious why you're seeing two orders of magnitude difference from
Omnibase for this simple example.  My personal experience is that
Omnibase is much faster than the current GOODS client (w/o WriteBarrier
which has never performed well in my applications) but your numbers seem
excessive.  I'm going to profile it myself so maybe we can compare notes
off-list and bring our results back when appropriate.

Looking at the GOODS code suggests one possible improvement for the
Squeak client.  I believe that GOODS supports a UNIX domain socket (as
well as the window's equivalent).  These tend to be much lighter weight
than full TCP/IP sockets.  Unfortunately I don't see a way to connect to
such a socket in Squeak.  The SocketPlugin could be copy/paste adapted
for such use.  It might be worth the work but we need more information
on bottlenecks first.

David