Hello Jiri, Thank you for your quick reply.
> What profiling technique are you using? Instrumentation? Sampling? ... Sampling, as this is the less intrusive of the performance tools. There is only a slight "wall clock" difference between a run with and without the performance monitoring. > > - With 2.5.0, I see that 33% of the (inclusive) time is spent in the > > DbDataAdapter.Fill method (the app is very data centric, so this is > > what I expect); that is 45 samples. > > > > - With 2.5.2, I see that 18% of the (inclusive) time is spend in the > > same Fill method; that is 59 samples. Hey, what is going on here ? > > I spend more time in the DbDataAdapter, and the % goes down ? First > > hypothesis: there must be some multi-threading involved here. > > Hard to say. Maybe the profiling technique resolution matters here. > > > What makes all my alarm bells ring is the following observation: > > > > - FbCommand.Dispose ................ 173 inclusive samples > > - Version10.GdsStatement.Dispose ... 168 inclusive samples > > - Version11.GdsStatement.Dispose ... 168 inclusive samples > > - System.Threading.Monitor.Enter ... 137 inclusive samples > > > > These methods were absent from the 2.5.0 performance samplings, so I > > suspect I missed some heavy architectural refactoring between 2.5.0 > > and 2.5.2. Can somebody confirm this? Or do I completely miss the > > point? > > There was fix to allow GC to collect freed commands before the > connection was disposed (hence also improving memory consumption). My application is single threaded. Does Firebird .NET create threads to handle some cleanup on its side? And from my understanding, my GC should also run 'synchronously' (i.e. I am not using the concurrent GC version, but the standard one). > > Seeing that my application is now spending more than 50% of its > > time in FbCommand.Dispose makes me feel queasy, not to mention the > > 42% in the lock() calls... > > There's a lot of wrongly and unnecessary placed locks in code. But I > don't have enough continuous time to do it, sigh. But I tried removing > most of locks in one code path in my private branch, and there was > roughly 1/3-1/4 speed improvement on 2CPU machine. So it's worth it. Hmm. That might be interesting to try. But the reason why I wrote in the first place -- that is: what are the architectural changes which would make the CPU spend about half of the execution time in the lock() in 2.5.2 and virtually no time there in the 2.5.0 version -- still needs clarifications, from my point of view. Pierre ------------------------------------------------------------------------------ _______________________________________________ Firebird-net-provider mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/firebird-net-provider
