Daniel Salama wrote:

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


Oops, :-[ , I didn't actually look at what you were storing.  Basically
you're writing to a single key in the BTree or Dictionary.  Assuming
that the starting array size for the Dictionary is reasonable I'm not so
surprised that BTrees and Dictionaries compare similarly.  Others have
suggested the existance of faster ways of generating primary keys (do
you really need them here?) which solves your performance problem for
this hypothetical situation.

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


Looks like the profile of a typical GOODS application...waiting on a
socket.  The good news is that Squeak is free to handle other users
during this time :-)  I don't know how much can be done to improve this,
asside from switching to UNIX domain sockets.  That might gain you a
factor of 2 or 3.  Probably not 100.  For my work right now it isn't
worth the effort (more on this in your  "other" thread).

Keep in mind the impact of the profile above on your application. 
Basically Squeak has to wait for the DB.  That means that each
individual user will see a certain "responosiveness" to your application
which might be slightly degraded due to this wait.  That responsiveness
is /not/ likely to degrade further due to GOODS as the number of users
increases (although it certainly will degrade due to Seaside/Kom) since
more users simply means more GOODS transactions waiting on sockets to
complete.  The actual performance of this application is not likely to
be severely impacted by GOODS unless you need to support large
transaction rates for a single individual.  Albeit this "application" is
pretty trivial.  A more typical GOODS application would have more data
flowing to the DB and the profile might look slightly different (waiting
on a socket to send data).  In that case you are in a position of
control.  If the application is too sluggish, optimize the organization
of your data to get it back to levels you want.  Due to the current
GOODS client performance, this tends to come up more often than I'd like
but I'd prefer spending time on this than dealing with SQL (or
frameworks like GLORP).  Omnibase is a nice middleground.  You have to
do work up front (makePersistent being the most intrusive) but it is
definitely more performant than Squeak<->GOODS is at the moment.  I'm
not telling you anything you don't already know, though.


>> 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 :)

I've saved the advice for the other, related, thread.

David