Potential causes of slowness #3009
Comments
Try to turn if off and see if intellisense will become faster (I tried, it didn't. I even forgot to turn it on back and had not mentioned it for a couple of days, then turn it on and nothing changed in the editor responsiveness).
It makes up to several calls for each long identifier (the one that has at least one dot in it's name). For example, for
Why batch the calls? The whole idea of the reactor is queuing as short tasks as possible, not few big ones. About typechecking itself, no idea, if you see a way, it would be great, obviously (same for "remove unused opens" and "remove unused declarations" code fixes).
Yes. However, it takes it about 40 seconds to fully process TypeChecker.fs. I find it strange that nobody has been interested in how it's implemented, nobody reviewed my PRs (yes, there are two or three of them), they were just merged without a question. Anyway, the code fix works totally OK for me. Maybe it's worth to add some heuristics to it, it could turn itself off if an iteration on a file completes in more than, say, 10 seconds. |
Reasons
But I agree reviewing needs to improve
OK. I'll keep an eye on it. It may also depend on other factors like how many errors in the file etc. I'll close for now but I suspect we may need to revisit this |
|
I'll reopen this While executing in Debug mode with "Output" window connected I found that key strokes were appearing very, very slowly. I looked at the output window and there was a constant stream of chatter related to this code fix It's hard to be sure but I think I saw about this much output come out between one or two keystrokes appearing: It's not total proof - the processing to the Output window may have been making things go slowly - and this was in debug mode - but it feels like we will need some other way to gate this so we never get in the way of typing, especially on slower machines. |
|
The multiple calls to BTW I actually wonder if we should no systematically pass in strings identifying which user operations are causing the FCS load, so from a single log we can see "ah, it is colorization" or whatever. Basically be more explicit about causality |
|
This is what I see after pressing one keystroke (space): |
|
On file change all the features get parse and check results and perform other calls. We have about 20 or so of them. Why is it a problem? |
|
That's on one keystroke. For example, operations like As I said, I don't know for sure. I don't want us to rush to turn off features either or to make other changes. This is debug code, with a debugger attached, and everything is slow like that. But I am experiencing plenty of slowness - both in debug mode and out - so I am trying to identify what the slowness is and what we can do about it. |
dsyme
changed the title
|
I noticed the same as you @dsyme ... I try to implement Code Lens in a performance friendly way, so that the feature won't add additional reasons for slowness. |
|
@vasily-kirichenko My current mission is to address the set of regressions that have crept in (partly so I can have a highly-usable set of tools to work on the compiler with). It's painfully slow going unfortunately. I'm just noting down what I see as I go along. |
|
@dsyme I suggest that I may take a look into this stuff because it breaks developing for me. |
|
To test if this is the cause of the problem, you can rebuild and install the Visual F# Tools with this code changed to just Follow DEVGUIDE.md to install the local bits. Once you've done that, try your solution and see if things are now fast. If we confirm this is the problem, you can then proceed to submit a PR which adds an options setting to enable/disable this feature (let's do that once the cause is confirmed) |
I doubt it's the problem. As you know that method just creates wrappers over cached Items, and there're not an awful lot of them even for a large file (up to 100K I think). What I agree with is that even typing is impossible if the debugger is attached to an exp instance. Maybe you are right and it is caused by large amount af debug output. I debugged Roslyn once (same as we do in this repo - F5 in the solution) and there was no slowdown at all - everything was flying. |
|
I was wrong about colorization. Roslyn asks as for classification spans for visible text only (and often line-by-line). We don't use GetAllUsesOfAllSymbolsInFile, we call GetSemanticClassification here https://github.com/Microsoft/visualfsharp/blob/master/vsintegration/src/FSharp.Editor/Classification/ColorizationService.fs#L43, passing the asked range. The range is used to filter out CapturedNameResolutions here https://github.com/Microsoft/visualfsharp/blob/master/src/fsharp/vs/service.fs#L1186. GetSemanticClassification returns |
|
Thanks, the solution helps a lot. Now it works again but I guess this still
should be investigated. I'll try to add an option.
Am 16.05.2017 1:36 AM schrieb "Don Syme" <notifications@github.com>:
… Hi @realvictorprm <https://github.com/realvictorprm>
To test if this is the cause of the problem, you can rebuild and install
the Visual F# Tools with this code
<https://github.com/Microsoft/visualfsharp/blob/master/src/fsharp/vs/service.fs#L2102-L2112>
changed to just
let projectReferences = []
Follow DEVGUIDE.md to install the local bits. Once you've done that, try
your solution and see if things are now fast. If we confirm this is the
problem, you can then proceed to submit a PR which adds an options setting
to enable/disable this feature (let's do that once the cause is confirmed)
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#3009 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AYPM8DvK-vOuDhoakJ8nmgh2JSxZvBWyks5r6OGTgaJpZM4NVKyv>
.
|
|
I just noticed that I forgot to rebase my code lens fork so I'm not sure whether it's not too outdated. So please stand by... |
I don't have any particular reason to suspect anything in colorization as being catastrophically bad, though it's plausible there are some operations which can be greatly improved. Looking through the various implementations of all the different operations in service.fs I see a lot of potential for small optimizations (e.g. |
|
@vasily-kirichenko I was wondering whether it could make sense to consider explicitly de-prioritizing some analyzers, e.g. via a technique like this: dsyme@1dc6ed2#diff-9fcad32e96ec98d48b0dff8fd7942e5aR29 I'm asking your opinion about this as a technique in general - not whether we should use it in any particular case. Would we just be introducing more problems, e.g. Would we be confusing Roslyn's analyzer scheduler (whatever that is), e.g. confusing it into thinking that some operations are longer-running (and hence it won't bother scheduling other work)? Is there a more declarative way to say something is relatively low-priority? |
|
@dsyme when was this feature you mentioned I should remove added? I updated my code lens to the latest master one week ago. |
I don't think analyzers hurt performance a lot. However, we could log how long each task was in the reactor queue until it was picked and output something like moving average of that time, grouped by operation name. About the technique, I don't think it makes sense. Roslyn calls analyzers with a longer delay than, say, coloring or symbol highlighting (I believe) already. What happens after a file change:
|
|
@realvictorprm See #3002 - which was a fix that enables the cross-project analysis feature in more situations.. I'm not saying you should remove cross-project references, but perhaps they should not be activated by default. |
|
@dsyme Thanks, yes I merged this one into my fork too so I guess my reports are valid. |
|
Closing old discussion issue |
Looking at the debug diagnostic trace, there is constant chatter where
SimplifyNameDiagnosticAnalyzeris making repeated calls toIsRelativeNameResolvableeven while no code is being edited.I think this may be making editing and intellisense sluggish. Each of the calls is relatively quick, but the overall effect is an awful lot of pressure on the FCS operations queue.
For example, see the tail of the "Output" window log below, after opening "Project.fs" in VisualFSharp.sln. This is only about 1% of the log. This is in debug mode so the times are slower than with release, but on a fairly fast machine.
I'm not sure whether the quick fix is "worth it" if we have to make an FCS call for every identifier in the document. If we can somehow batch the calls or do the analysis as part of typechecking itself then maybe?
Also, is the
SimplifyNameDiagnosticAnalyzeronly being run on the currently open file?The text was updated successfully, but these errors were encountered: