David,

On Apr 13, 2005, at 8:46 AM, David Shaffer wrote:

> 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.

One thing to keep in mind is that, for this test, the GOODS database is 
completely empty. This means that the only contents it has is the data 
for this test, which is simply an integer counter.

>
> 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 haven't profiled it yet, so I did it now on the following code:

MessageTally spyOn: [
time:= Time millisecondsToRun:
[Transcript cr..
db := KKDatabase onHost: 'localhost' port: 6100.
db root: (BTree new).
db commit.
db root at: 0 put: (BTree new).
db commit.
base := db root at: 0.
nextCustomerNo := base at: 0 ifAbsent: [0].
[0 to: 999 do:
	[:i|
	(i \\ 100) = 0 ifTrue: [Transcript show: '.'].
	nextCustomerNo := nextCustomerNo + 1.
	base at: 0 put: nextCustomerNo.
	db commit]] ensure: [db logout]].

Transcript cr; show: (time/1000) asFloat; show: ' seconds'.

db := KKDatabase onHost: 'localhost' port: 6100.
base := db root at: 0.
Transcript cr; show: 'Last Customer No: '; show: (base at: 0).
db logout.
].

And the results were:

  - 203964 tallies, 206040 msec.

**Tree**
98.4% {202743ms} KKDatabase>>commit
   98.4% {202743ms} KKDatabase>>commitOnFailure:
     97.9% {201713ms} KKKeyCache>>commit
       97.9% {201713ms} KKRecordCache>>commitObjects:
         96.5% {198829ms} KKConnection>>commitRecords:
           96.5% {198829ms} KKConnection>>receiveTransactionResult
             96.5% {198829ms} KKConnection>>receiveHeader
               96.5% {198829ms} KKConnection>>receiveIntoHeaderBuffer
                 96.5% {198829ms} KKConnection>>receiveFullyInto:
                   96.5% {198829ms} Socket>>receiveDataInto:startingAt:
                     96.5% {198829ms} Socket>>waitForDataIfClosed:

**Leaves**
97.7% {201301ms} Socket>>waitForDataIfClosed:

**Memory**
	old			+299,104 bytes
	young		-193,680 bytes
	used		+105,424 bytes
	free		-105,424 bytes

**GCs**
	full			0 totalling 0ms (0.0% uptime)
	incr		530 totalling 840ms (0.0% uptime), avg 2.0ms
	tenures		3 (avg 176 GCs/tenure)
	root table	0 overflows

I haven't really analyzed the results yet, for this is the first time I 
ever see this and learned about this feature. Hopefully it provides 
more information to you.

> 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.

I agree and that's the reason why I'm requesting help/advice :)

>
> 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.

Don't know much about it, but makes some sense. Hopefully this can be 
easily fixed.

Thanks,
Daniel