On Dec 31, 2003, at 6:28 AM, Vaidas Didzbalis wrote:

> Hi,
>
> Why next commit on takes so long even if I’ve changed nothing since 
> first one?

Hi Vaidas,

The commit has to check each object in the local cache to see if it has 
changed.  Normally, there are few enough objects cached (most of them 
being stubbed out by proxies) that this isn't a performance  problem.  
KKDatabase>>flush and #flushAll are provided to help keep the cache 
small (these will stub out as many objects as possible, using an 
incremental and full GC respectively).  However, objects that you have 
committed in the current session don't have proxies, and so can't be 
stubbed out - they'll always be in the local cache.  So once you've 
committed huge numbers of objects in one session, yes, further commits 
will be slow.  I don't think this is a common use case in real life.

Try grabbing a new connection right after your large commit, and you 
should see much better numbers.

One GOODS optimization that would also make your particular test faster 
would be to declare certain objects (eg Numbers) as immutable, so they 
wouldn't ever be checked for changes.  Actually, I could swear I added 
that optimization, but I can't find it in the code, so maybe I never 
got around to it (or realized why it was a bad idea).  I've just gotten 
back from three weeks of code-free holiday, so it's all a little 
fuzzy...

> db := KKDatabase onHost: ' localcost' port: 6100.
>
> root := db root.
>
> nt := OrderedCollection new.
>
> root at: #NumbersTable put: nt.
>
> db commit.
>
> 1 to: 1000000 do: [:e | nt add: e]
>
> [db commit.] timeToRun. <31158>
>
> [db commit.] timeToRun.<16875>
>
> Thank you.
>
> Vaidas
>
>
>