Again Magma and 3.9

[Chris Muller]

> Ok, we now tried to insert 1000 entries and got a MessageTally of it.
> It
> seems, that we are waiting for the TcpSocket very long, meaning that
> the
> server is too slow?
> 
>   - 32310 tallies, 32366 msec.
> 
> **Tree**
> 98.8% {31978ms} CWDatabase class>>initialSetup
>    80.3% {25990ms} CWDatabase class>>initialSetupCityDBOn:
>      |80.3% {25990ms} CWDatabase class>>loadCityDBFromFile:on:
> ...

Hi Martin, thanks for the MessageTally, it reveals a lot and helps
communication.

Although there were 24 seconds spent doing the first commit of 1000,
after eliminating "one-time" items that only occur on this first commit
(see my breakdown below for details), it looks like subsequent batches
of 1000 should take around 10-11 seconds each (total roundtrip), which
is about what I would expect.

Of this 10 seconds each, probably about half is spent updating the
back-end index files.  For a long time I have considered making these
updates asynchronous; perhaps now is the time to do it.  It just
doesn't make sense to hold everyone up while all possible keywords are
inserted into a keyword index.

So, with bulk-load best-practices on the client (i.e., stubOut:,
commitAndBegin:, etc.), combined with asynchronous index updates on the
server, this would probably get you down to about 5 seconds per 1000
objects, and maybe even faster if you could use multiple images
connected to one server.

Would that meet your performance requirements or still too slow?

Regards,
  Chris

"breakdown of the MessageTally"
  2.5 seconds to make the one-time initial connection
  1.1 seconds to do the one-time initialize of the serializer(s)
  ~4 seconds to do the serialization of the model loaded from the file.
  ~4 seconds to do a one-time extra serialize due to adding a new
MagmaCollection and new class-definitions to the repository-definition.
  3.5 seconds to do the one-time, enumeration of the collection (this
is actually not necessary for a new collection, so this was two
unnecessary requests; I will fix this)
  13 seconds in the server, but this includes the extra enumeration, so
its probably less.