Internally use StreamAsync for FindAsync()

[Eli-Black-Work]

It seems there's a well-known problem where EFCore is very slow when doing FindAsync() on a table that involves a VARCHAR(MAX) column. (#22331)

After reading dotnet/SqlClient#593 (comment), it looks like the ADO.NET StreamAsync methods are faster than the Async methods.

Does EFCore use ADO.NET internally? If it does, could the EFCore team modify FindAsync() to internally use StreamAsync, so that FindAsync() has decent performance even when selecting columns of type VARCHAR(MAX)?

Thanks, and sorry for the newbie question 🙂

[roji]

While it's technically possible to modify EF Core's materialization to use GetTextReader and GetStream for the problematic field types, this would have affect other relational provider as well (not just SQL Server), and may slow down access to small values of VARCHAR(MAX) (we'd have to check this).

We generally try to avoid working around issues and bugs in lower layers (SqlClient in this case) - the recommended workaround is to not use async I/O (e.g. call Find instead of FindAsync) until SqlClient fix the issue on their side.

[ajcvickers]

Discussed in triage and agreed this is not a direction we want to go.

[Eli-Black-Work]

Ya, I didn't think about the fact that this would affect other providers. Thanks for the responses 🙂

Would still like to see this get fixed in SqlClient, of course 🙂 We had fixed a bunch of async-related warnings in VS and then lost a couple of days trying to figure out why our DB-related code had slowed to a crawl.