WOW ! ! ! :-D I just like to have some profiling done with an external mapping...
Could XmlMappingSource become in some way lazy? I wonder if it would be needed, since the mapping could be fully loaded and reused (it has no public constructor, I think to suggest such usage way). A question: doing the same query twice on the same DataContext, would gain the same time for step 2? Giacomo On Wed, Jun 17, 2009 at 9:54 PM, Jonathan Pryor <[email protected]> wrote: > > On Wed, 2009-06-17 at 03:49 +0000, Jonathan Pryor wrote: > > Things I find truly interesting is that the DataContext constructor is > > *slow* (which shouldn't be too surprising, as Adrus Moor already told us > > this), but at 348820 ticks to execute it is the most expensive step, > > taking over 3x longer than actually executing the SQL query. > > > > This is insane. > > And this has been improved by making AttributedMetaModel lazily > initialize itself in r1171. > > Before r1171, DataContext construction was around 350000 ticks within > the unit tests. > > In r1171, DataContext construction is around 400 ticks. > > Yes, that's around 875x faster. > > It's not without it's tradeoffs, though. > Test_NUnit_MsSql.AnyCount.CountExternal03: > > Before: > Step 1: 348820 ticks > Step 2: 21105 > Step 3: 133918 > Step 4: 1850 > Step 5: 114779 > Total: 620570 > > After [0]: [ (new / old)*100 % ] > Step 1: 433 ticks [ 0.12% ] > Step 2: 244219 [ 1157.16% ] > Step 3: 45254 [ 33.79% ] > Step 4: 2062 [ 111.46% ] > Step 5: 90545 [ 78.89% ] > Total: 382781 [ 61.68% ] > > So for this test, step 2 (the Expression<T> creation) was > *significantly* slower, taking ~12x longer. Step 3, meanwhile, was ~3x > faster, while steps 4 and 5 were roughly comparable (-ish). > > Despite Step 2 taking ~12x longer, the entire test ran faster. > > That's a trade-off I'm willing to make. :-) > > Next we look at > Test_NUnit_MsSql.ReadTest_Complex.F26_DistinctUnion_Count: > > 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% ] > > All I can say is, _wow_. > > With a win like that, I'm wondering if I need to make anything else > lazy... > > (With wins like that, I wonder if QueryCache is needed as much any > more...) > > 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. > > Furthermore, while debugging this I'm seeing that some of the laziness > is defeated, as AttributedMetaAssociation.SetupRelationship() starts > pulling in more and more types. However, at least it's restricted to > just the T in Table<T> that's being accessed, instead of all types all > at once (which should still speed up things for Andrus Moor). If I'm > lucky this can be made even lazier. > > - Jon > --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
