Drastic performance difference between using SqlClient and SSMS

We’re currently saving a complex object structure in XML form. For safety and convenience we’re using an SQL Express Server for handling the data. Right now we save the full document once every time changed (biggest being around 28MB of size) which should be no problem for SQL Server to handle.

The data is stored in a table with “Id (int, PK, Identity), Revision (int), Timestamp (datetime2), Data (xml)”. When I run the following query on SSMS (with Execution Plan), I see that it runs a clustered index seek which obviously doesn’t take long for a table with ~600 rows. Using the SQL profiler I get the full XML data (non-trimmed) in 184ms (CPU: 47, Reads: 27044).

Now I do the very same thing in my application using plain SqlClient connection with the very same query: 36923ms (CPU: 47, Reads: 18286)

It’s the exact same query when I look at the Profiler. Yet it takes ages longer until the query completes. And after that it also takes quite a while until ReadAsync() returns back with the XML data.

Can anybody explain to me why this happens? We currently have load times up to 6 minutes where as ~2.5 minutes are just retrieving the latest data from SQL Server.

As for the connection: The server is only running with TCP/IP protocols enabled.

[Wraith2]

In the end avoiding async/await here does not have any performance impact except speeding it up a lot.

If you don’t need that thread to be available for other work while it’s waiting for network packets then that’s ok. If you’re in a situation where many threads are competing for cpu time async would be better. Depends on your use case.

It might be possible to port the core fix to desktop. I haven’t looked. I choose to contribute my time to core issues since I know that codebase better and it’s where I wanted performance improvements.

[Skyppid]

I could but then I’d ask myself whether I should really upgrade to .Net Core if there are issues that severe… Nonetheless, it has changed nothing at all.

What I do see though in the time this query executes is that the GC is running like hell. I analyzed the heap and there are 3.023 TdsParserStateObject+PacketData objects on the heap totalling in ~25 MB memory. I see them less with the project targeting .Net Standard.

Anyway, still poor performance … it takes way too long for 25MBs of data to retrieve from SQL Server.