Performance metrics - some early conclusions

[Ed Kleban]

I was getting rather pissed that that Valentina appeared to be much slower
that my intuition led me to believe would be the case.  It shouldn't take 20
times longer to add a 2-field entry into a table record for every node in an
XML Parse tree than the time required to build the parse tree from XML in
the first place.  Then I noticed that the disk was thrashing for what was
supposed to be an all in-memory table.

I eventually figured out the problem, tweaked things up, and have come to
the following VERY preliminary conclusions about Valentina performance under
RB 2005:

=========  

Generating a 400 MB file by failing to turn of V4RB debug logging may cost
you at least factor of 20 in performance degradation.

Variant.Hash is not unique for in-memory objects in RB 2004 r5 despite the
language reference claim to the contrary.  It appears this may be a bug in
multiple RB versions going back to 5.x.

Adding a record in a table with twice as many fields will likely take about
twice as long, as you would expect.

Re-indexing or enabling indexing on a non-indexed field is very expensive.

Indexing a field after first populating it for all your records can save you
time, perhaps 15%.

It takes about half as long to store an object hash in a memory buffer field
as it does for Variant.hash to calculate the value.  Considering that
Variant.hash is presumably basing the hash on the address of an object,
that's darn impressive.

It is indeed possible to list all of the nodes in an XML parse tree in an
in-memory table in perhaps 20% less time that it takes to build the parse
tree from XML source using Theo's bat-out-of-hell XML Engine.  That bodes
very well for overall performance.

Bottom line:  I'm a happy camper :)