sorry... ignore the previous mail's question :-D
On Thu, Jun 18, 2009 at 2:30 PM, Giacomo Tesio <[email protected]> wrote: > 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 -~----------~----~----~----~------~----~------~--~---
