On Wed, Jun 17, 2009 at 9:54 PM, Jonathan Pryor <[email protected]> wrote:

>
>
>        Before:
>         Step 1:  360714 ticks
>        Step 2:  104669
>         Step 3: 2829379
>        Step 4:  549125
>        Step 5: 2241118
>         Total: 6523817
>
>        After [1]:            [ (new / old)*100 % ]
>        Step 1:     369 ticks [   0.10% ]
>        Step 2:  128496       [ 122.76% ]
>        Step 3:  252783       [   8.93% ]
>        Step 4:    8302       [   1.51% ]
>        Step 5:  137859       [   6.15% ]
>        Total:   528024       [   8.09% ]
>
> Analysis?  Alas, I can't say _why_ this is happening, but I can
> conjecture (badly).  Step 2 is uniformly slower because the table
> loading that used to be performed in the AttributedMetaModel constructor
> is now performed during DataContext.GetTable<T>() (via
> AttributedMetaModel.GetTable(Type)), so it's largely a movement of time
> accounting away from the constructor into Step 2.


Thinking a bit about this result I've found quite strange that even Step4
and Step5 take such a big improvement.


This could be related to the build of the datamapper which actually use the
mappings.

Lazyness should be a possible problem for these steps, while it's not.

Why?

Becouse of lookups. In a Dictionary, for example, as far as the cache
increase it's dimension the hash collision grows. This lead to comparing
elements present to identify the which wanted.
In a List this is problably worse.

So keeping (relatively) short lived datacontext improve performances (for
example a DataContext instance could be an http request singleton used
during each Controller/Presenter or model operations).


But what if the DataContext MUST be longlived?
And what if the MappingSource comes from a stream (like XmlMappingSource
does)?
Such a stream based mapping need to parse the stream as it comes, so that
lazyness could be problematic.

The XmlMappingSource and the AttributeMappingSource have probably an
internal cache (a Dictionary? who knows?) which must have a fast lookup.

This is something that we need to look at, since for example on
XmlMappingSource we could get the Step1 improvement by simply sharing the
mapping source between datacontexts, but no way to get the same from the
other step if my guess about lookups is right.


Giacomo

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups 
"DbLinq" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to 
[email protected]
For more options, visit this group at 
http://groups.google.com/group/dblinq?hl=en
-~----------~----~----~----~------~----~------~--~---

Reply via email to