Nullable tests

[Daniele Teti]

Hi guys,

talking with Marcos, I'm reconsidering the nullable types.

My bigger concern is about performances.

In the attached file, you can evaluate how much the mechanism will slow down dorm.

This is a really simple implementation of nullables. My target is to compare how much "AT OUR BEST" we'll slow down dorm introducing nullables.

Any comments?

--
--------------------------------------------
Daniele Teti
R&D Director & Educational @ bitTime Software
http://www.danieleteti.it

[Marcos Barreto]

Daniele i did other test, more related with how the DORM will use this Nullable types.
My doubts was about filled the nullable properties's object then I chage your tests to something like:

    for i := 1 to 10000000000 do
      v := i;    // 1sec

    for i := 1 to 10000000000 do
      ni := i;   // 8sec

    for i := 1 to 100000 do
      s := inttostr(i);   // 7msec

    for i := 1 to 100000 do
      ns := inttostr(i); // 11msec


Like we can see i think that to use nullable into dorm can be better that not to use.

[Marcos Barreto]

The result for that that cannot compile the project
remembering that to integer and nullable<integer> we have loop of 10.000.000.000 operations
remembering that to string and nullable<string> we have loop of 100.000 operations

ASSIGNING ====================================
finished Integer: 1410065408 - elapsed: 1039
finished Nullable<Integer>: 1410065408 - elapsed: 8564

finished string - elapsed: 6
finished Nullable<Nullable> - elapsed: 10
==============================================


SUM/CONCATING ================================
finished integer: 1410065408 - elapsed: 1003
finished nullable<integer>: -1474836480 - elapsed: 9034

finished string - elapsed: 8
finished nullabel<string>  - elapsed: 18786
==============================================

[Claudio Regonat]

I Agree with you Marcos,

i think that a nullable type won't introduce
a noticeable performance glitch, because as
you say most of the use will be for assigning, and
normally you don't have so many nullable fields in a
database.
Also, what we should consider is that if we refactor
the adapters we can use joins for loading related objects.
That would be a performance gain that will compensate the
nullable effects.

Saludos.

[Marcos Barreto]

I think that are other places where we can speed peformance too.
MappingTable and MappingFields for sample. We could store the RTTIContext on mappingtable then pass this rtticontext to mappingfield too
then store into mappingfield you TRttiproperty or TRttifield, so we can during sql generations do loop on mappingfields instead object´s properties.

[Marcos Barreto]

I think that penalities of peformance will evolve more the application that DORM.
for sample:
the user implement a loop concating nullables, when could had to use a temporary native type and after loop, assign the value to nullable type!