DataAccessPerformance
DataAccessPerformance copied to clipboard
Meeting notes 11/13/2017
Attendees: @anpete, @divega, @geleems, @sebastienros, @vancem
In today's meeting @vancem described an investigation the did several months ago of the TechEmpower Fortunes benchmark using SqlClient. Thanks for all the great information!
Here is a summary of his findings:
We are CPU bound. Thus it is about removing CPU overhead.
Recommendations:
-
More efficient building of HTML string. Option 1) Improve StringBuilder to avoid copies. i. Define a StringBuilder.ForeachChunk(Func<Span
>) to characters from a StringBuilder without making a large string (e.g. ToString()).
ii. Allow StringBuilder.Append(int) to take a CultureInfo so that string writing can be done without making a string) Option 2) (Larger) Make a UTF8String based StringBuilder and use that. (e.g. System.Text.Primitives). -
(4%) There are hot locks in system.data.sqlclient a. (2.7%) system.data.sqlclient!System.Data.ProviderBase.DbConnectionPool.PrepareConnection b. (.3%) system.data.sqlclient!System.Data.SqlClient.SqlConnection+OpenAsyncRetry.Retry c. (.5%) system.private.corelib!System.Threading.TimerQueueTimer.Change
-
In general optimize system.private.corelib!System.Threading.TimerQueueTimer.Change
-
Converting to Unicode when deserializing from the database.
-
Change benchmark to use Ordinal Sorting (today it uses culture aware)?
-
Fix system.data.sqlclient!System.Data.ProviderBase.DbConnectionPoolIdentity.GetCurrent on windows to cache the windows identity, or to mimic what Linux does. (10%)
@saurabh500 @geleems this is relevant to the discussion we had today.
Thanks @divega