Fsharp: Unacceptable completion performance on a project that has ProvidedTypes.fs(i) included

[vasily-kirichenko]

15.7.1

1. git clone https://github.com/fsprojects/FSharp.Data.SqlClient.git
2. cd FSharp.Data.SqlClient
3. build Build
4. Open SqlClient.sln
5. Open DesignTime.fs file
6. Go to line 347, for example
7. Add an empty line
8. Type "L" character
9. Wait for completion
10. It takes about 5 seconds to get the completion, devenv.exe consumes a lot of CPU
11. Delete the "L", repeat
12. Completion takes the same long time to appear

Looking at the reactor logs:

• DesignTime.fs is checked instantly
• Background checking blocks the reactor thread for more than 3 seconds

I think something wrong with caching background check results: the huge ProvidedTypes.fs seems to be rechecked every time on any ParseOnCheckFileInProject call.

Reactor: 77,745.864 BAD-BG-SLICE: >3s <-- background step, took 3982.1349ms

[vasily-kirichenko]

Tested on the latest nightly build: the same.
Tested on VS 2015: the same o_O

[vasily-kirichenko]

It turns out the problem is not caused by ProvidedTypes.fs. I've created a minimal repro: https://github.com/vasily-kirichenko/SlowTypecheckRepro

Settings:

[smoothdeveloper]

Maybe amount of overloads in some types of this assembly?

[vasily-kirichenko]

@smoothdeveloper maybe.

Does anybody remember a packages with a type with LOTS of overloads?

[forki]

Yes overload resolution is sloooooow

Vasily Kirichenko [e-mail] schrieb am Di., 22. Mai 2018,
12:53:

@smoothdeveloper https://github.com/smoothdeveloper maybe.

Does anybody remember a packages with a type with LOTS of overloads?

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/Microsoft/visualfsharp/issues/4961#issuecomment-390948358,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AADgNOcL7wPY8uTNQoPGRFNeLZP-A4LJks5t0-4lgaJpZM4UHi0b
.

[vasily-kirichenko]

[vasily-kirichenko]

[vasily-kirichenko]

[vasily-kirichenko]

Why Visit is non optional:

even though it's virtual, not abstract:

[forki]

can you see what part of isexactmatch is slowest?
from very quick review I can see that CompiledSigOfMeth is called with same arg in IsExactMatch and in IsPartialMatch

[forki]

and in IsTyparKindMatch

[vasily-kirichenko]

Yes, I've optimized away the double call of CompiledSigOfMeth. But I think the problem is that all _virtual_ methods are checked (> 1000), because for abstract classes all methods are marked as required to implement:

https://github.com/Microsoft/visualfsharp/blob/4eed66b39d0db4c3c2d63bf11e98f4ea3f30be4c/src/fsharp/MethodOverrides.fs#L461-L478

[vasily-kirichenko]

What if filter dispatch slots by minfo.IsAbstract = true?

[forki]

https://github.com/Microsoft/visualfsharp/pull/4970

[vasily-kirichenko]

With https://github.com/Microsoft/visualfsharp/pull/4971

[vasily-kirichenko]

Found this https://github.com/Microsoft/visualfsharp/blob/master/src/fsharp/MethodOverrides.fs#L320
This is iteration over dispatchSlots, which is done inside List.iter over the same dispatchSlots, so for 1K overloads, IsExactMatch was called up to 1M times :(

[dsyme]

1000 overloads. My oh my.

[forki]

Looks like they are doing something like a discriminated union - just without DUs in the language.

[vasily-kirichenko]

Fixed via https://github.com/Microsoft/visualfsharp/pull/4971

[abelbraaksma]

I do have a project with an often used create method with over 300 overloads (use case interoperability with c# for otherwise inlined methods). Can I help with testing something? I do have issues with performance in general and completion, quickinfo and colouring specifically. It may be related.

[vasily-kirichenko]

@abelbraaksma just install the nightly vsix and try https://blogs.msdn.microsoft.com/dotnet/2017/03/14/announcing-nightly-releases-for-the-visual-f-tools/