Performance metrics - some early conclusions

[Ed Kleban]

On 11/30/05 9:48 AM, "Ruslan Zasukhin" <sunshine at public.kherson.ua> wrote:

> On 11/30/05 5:33 PM, "Ed Kleban" <Ed at Kleban.com> wrote:
> 
>>> Have you specify
>>>     Table.SetBlank( forAdd )
>>>                     ^^^^^^^
>>> This can give 20% speedup
>>> 
>> 
>> Yes, I recently  went through and put in "forAdd" in all my SetBlank calls.
>> But since I typically do a SetBlank just once before entering a loop to set
>> memory buffer fields and do an AddRecord for hundreds of records, It doesn't
>> really have much affect.
> 
> In fact this is wrong.
> 
> It can kick you IF you have BLOB fields.
> For BLOB fields, it is VERY important that you SetBlank() on each iteration.

Ah, good to know.  Ok, so noted.  This will be very easy since I only intend
to have a single VarChar and a single Blob field in the entire database, and
those are both accessible by only a common, well-encapsulated function.

In essence I have a "BDataStore" class that has a single call allowing you
to intern an arbitrary RB string and returns a signed recId.   If the recId
is positive, the string was already found, or was just added, at the
specified recId in a table having a VarChar and Vlong hash fields.   If the
recId is negative then the string was already found, or was just added, at
the absolute value of the recId in a table having a Blob Text and a Vlong
hash field.

Strings are represented by one of these Vlong BDataId values in all other
database fields that require a use of a string.  Thus each string gets
stored only once no matter how many times it appears in the application
source, all string lookups are hashed, all string references require only a
Vlong for storage, all string comparisons are as fast as integer
comparisons, and constant BDataID values can be used to make instant string
comparisons for commonly compared strings.

Less filling, works great, runs very very fast.