Improve IDE (design-time) performance

[cmeeren]

I love SqlClient, but one thing that consistently gets me down is that as my DB file grows, things slow to a crawl in Visual Studio. We're talking about 5–10 seconds after each edit before Intellisense catches up, not to mention that editing in general is slow. When that happens, I effectively have to sacrifice productivity for type safety in using SqlClient.

Might there be some low-hanging fruit that could improve the design-time performance of SqlClient, or is this simply a fact of life with type providers?

(Note that SqlClient in my case is running against a localhost database, so there should be no network overhead.)

[charlesroddie]

is this simply a fact of life with type providers
editing in general is slow

This is what SSDT is good for. Get better and faster intellisense when writing SQL, and then once it's finished let FSharp.Data.SqlClient manage the interface to F#. (With a 10s lag for a build.) Using FSharp.Data.SqlClient to help edit the SQL is not the best solution.

[cmeeren]

Perhaps I wasn't clear enough; I was talking about F#/.NET intellisense, not SQL. (I'm using separate SQL files.) I'm not using SqlClient to help edit the SQL.

[smoothdeveloper]

@cmeeren it is not clear to me if the issue is with F# tooling at large, or specific to (or let say significantly worsenned by) this SQL type provider, I've seen performance issues with tooling in different contexts.

If you have a very minimal sample using the provider that show poor performance, we can investigate a bit if the time is spent in the provider code or in the IDE itself, in which case it is worth reporting the case on dotnet/fsharp.

[cmeeren]

it is not clear to me if the issue is with F# tooling at large, or specific to (or let say significantly worsenned by) this SQL type provider

In case it helps: For files of equal length (say, 3000 lines), a file with lots of SqlClient usage (say, 50 functions using SqlFile and SqlCommandProvider) has terrible performance while a file with no SqlClient usage has acceptable performance.

I currently have no minimal sample. I will keep it in mind, but unfortunately I have my hands full for the time being.

[charlesroddie]

As our queries have grown (93 functions + procedures defined in SSDT) we are getting perf from FSharp.Data.SqlClient that is becoming unmanageable. About 4s from a minor edit of non-sql-related F# code to intellisense catching up.

What is happening when an sql-unrelated change? Is SqlClient unnecessarily parsing the sql again and creating new types? Is that an SqlClient bug or an F# type provider problem?

(cc: @kevcrooks)

[smoothdeveloper]

maybe related: dotnet/fsharp#10159

[smoothdeveloper]

Closing, we'd need more specific / reproducible description of the issue.