Codist 6.5 Beta

[wmjordan]

Download

Codist 7379

Codist 7367 Codist 7359

What's new

• General
  • [ ] Addressing memory leaks in WPF and Codist (7367, 7379)
• Syntax Highlight
  • [x] Highlight is now updated when external files have been changed (7359)
  • [x] Highlighted lambda expressions that capture external variables (7379)
• Super Quick Info
  • [x] Fixed Suppress Super Quick Info when Ctrl key is pressed option was not working as expected (7379)

[wmjordan]

@fitdev

I recently found that Codist was causing some memory leaks in VS, hence made this beta version.

This new beta also fixed a problem that if a symbol is renamed or removed from another file, other files won't update the syntax highlight. Now Codist manages to detect that situation.

Please download and check to see whether it works well at your side.

[fitdev]

Thank you for all your work. I will give the new beta a try soon. Though I have not noticed any of these 2 issues. What I did notice lately though was that Super Quick Info would sometimes stop working and revert back to the VS default one. Reopening the document does not fix it - only a full VS restart is needed. I do not know the exact circumstances when it happens, but am pretty sure it happens once the CS Code Refactoring Provider or similar analyzer crashes in VS at least once, but it maybe just a coincidence.

[wmjordan]

After upgrading to the recent 17.3 preview 6, I did experienced some weirdness at the first a few sessions working with VS. However, VS appears to be OK after then. Nevertheless, I had not encountered that Super Quick Info stopped working.

[fitdev]

I will keep a closer eye on it to try to notice exactly when it stops working and let you know if I discover something more concrete.

[fitdev]

I noticed that the latest VS 17.4 Preview 1 started freezing for a few seconds with the latest version of Codist whenever I would type one of my user-tagged comments, with the following stack in one of the threads:

0, ntoskrnl.exe!KeWaitForSingleObject+0x30c1
1, ntoskrnl.exe!KeWaitForSingleObject+0x1521
2, ntoskrnl.exe!KeWaitForSingleObject+0xadb
3, ntoskrnl.exe!KeWaitForSingleObject+0x1ff
4, ntoskrnl.exe!ExWaitForRundownProtectionRelease+0x9fa
5, ntoskrnl.exe!KeWaitForSingleObject+0x31cb
6, ntoskrnl.exe!KeSynchronizeExecution+0x2e02
7, Roslyn.Utilities.EventMap+<>c__DisplayClass4_0`1[[System.__Canon, mscorlib]].<RemoveEventHandler>b__0(Registry`1<System.__Canon>) + 0x15 <-- Microsoft.CodeAnalysis.Workspaces.ni.dll+0x13fe2c5
8, System.Collections.Immutable.ImmutableArray`1[[System.__Canon, mscorlib]].RemoveAll(System.Predicate`1<System.__Canon>) + 0x75 <-- System.Collections.Immutable.ni.dll+0xf62f5
9, Roslyn.Utilities.EventMap.RemoveEventHandler[[System.__Canon, mscorlib]](System.String, System.__Canon) + 0x122 <-- Microsoft.CodeAnalysis.Workspaces.ni.dll+0x13fe0e2
10, Codist.Taggers.CSharpTagger+ParserTask.Disconnect() + 0x80 <-- 0x7ff8a3e1fed0
11, Codist.Taggers.CSharpTagger+ParserTask+<ParseAsync>d__15.MoveNext() + 0x366 <-- 0x7ff8a2076df6
12, System.Runtime.CompilerServices.AsyncTaskMethodBuilder.Start[[Codist.Taggers.CSharpTagger+ParserTask+<ParseAsync>d__15, Codist]](<ParseAsync>d__15 ByRef) + 0x80 <-- 0x7ff8a2076860
13, Codist.Taggers.CSharpTagger+ParserTask.ParseAsync(System.Threading.CancellationToken) + 0x59 <-- 0x7ff8a20767a9
14, System.Threading.Tasks.Task`1[[System.__Canon, mscorlib]].InnerInvoke() + 0x4e <-- mscorlib.ni.dll+0x5fbe4e
15, System.Threading.Tasks.Task.Execute() + 0x47 <-- mscorlib.ni.dll+0x5faf27
16, System.Threading.ExecutionContext.RunInternal(System.Threading.ExecutionContext, System.Threading.ContextCallback, System.Object, Boolean) + 0x172 <-- mscorlib.ni.dll+0x58df12
17, System.Threading.ExecutionContext.Run(System.Threading.ExecutionContext, System.Threading.ContextCallback, System.Object, Boolean) + 0x15 <-- mscorlib.ni.dll+0x58dd95
18, System.Threading.Tasks.Task.ExecuteWithThreadLocal(System.Threading.Tasks.Task ByRef) + 0x231 <-- mscorlib.ni.dll+0x5fb1e1
19, System.Threading.Tasks.Task.ExecuteEntry(Boolean) + 0xa1 <-- mscorlib.ni.dll+0x5fa8c1
20, System.Threading.ThreadPoolWorkQueue.Dispatch() + 0x156 <-- mscorlib.ni.dll+0x558e46

So, maybe this should not run on every keystroke?

[wmjordan]

I also noticed the interface got frozen this afternoon, while I was undoing some changes. I observed similar stack trace information as yours in WinDbg.

However, it did not bother me in VS 17.3. Could it be an issue in Roslyn?

I am addressing the memory leak issue the recent days, and may be the recent changes in Codist can be the cause for this issue too.

Does this issue occur very often on your side? Could you help try rolling back Codist to the prior version (6.4) and see whether this issue persists?

[fitdev]

Thank you for a quick reply! A small update: turns out that this happens also even when typing an xml doc comment too, which should not be affected at all by custom comment user tags.

Yes, perhaps it could be a Roslyn issue, though I still think that it does not make sense to run this relatively expensive operation on every keystroke, which is what it seems it is doing.

I have not noticed memory leaks myself in any version of Codist, but I cannot say I have looked carefully, and although my VS sessions last a few days usually (without restarting VS), I do have a lot of RAM, so even if there is a small leak I might not notice it.

Which version of Codist do you suggest I rollback to? Do I uninstall the current version first?

[wmjordan]

Version 6.4 (the one in the VS marketplace) will be OK. You have to uninstall the 6.5 beta before installing the 6.4.

[fitdev]

I see. I will do that ASAP and let you know.

An aside, a small feature request: It would be real nice if for the Super Quick Info, whenever it lists a list of implemented Interfaces (for either a class, struct, or interface), in case where such interfaces are inherited, it would not just show "IInterfaceName (inherited)", but also show where it was inherited from, i.e. "IInterfaceName (inherited from [ClickableInterfaceName])"

[wmjordan]

It would be real nice if for the Super Quick Info, whenever it lists a list of implemented Interfaces (for either a class, struct, or interface), in case where such interfaces are inherited, it would not just show "IInterfaceName (inherited)", but also show where it was inherited from, i.e. "IInterfaceName (inherited from [ClickableInterfaceName])"

It is not so difficult to do so. However, what's the benefit of this? While you hover your mouse cursor onto a Dictionary<,>, or ConcurrentDictionary<,>, the list is already somewhat long long and it will become somewhat fat, if this feature is implemented.

[fitdev]

The benefit is at least for me, I often deal with Interfaces that form long and complex hierarchies (chains of inheritance that may be ~10 items long), and I do not easily remember how a particular interface is inherited, yet this information may be very useful in interface design of complex hierarchies that I deal with (as some consuming interfaces may not need all the base interface members or may use DIMs to re-implement them). So for me at least, it would be quite useful!

[fitdev]

I downgraded to version 6.4 from VS Marketplace as you suggested, and it seems the freezes are gone - all is working fine now! So apparently they are a result of something you introduced in this new beta.

[wmjordan]

Ok, let's work with that version for some time. The problem lies in the line that detach an event handler from Roslyn's Workspace. It somehow introduces lock contentions. I will try to find another way to release the resource.

[wmjordan]

@fitdev Please try the recently released beta and see whether it performs well.

[fitdev]

Thank you for the new version. So far it seems to be working well. I will let you know if I experience slowdowns. Out of curiosity: what did you change?

[fitdev]

No, sorry, spoke too soon. Still get the same freezes when typing in comments with the latest beta. Will be reverting to the older version once again.

[wmjordan]

Thank you for testing. It should have nothing to do with comments. Every edit operations may cause the freeze, if it occurs.

I will check to see what I can do with it later.

[fitdev]

It should have nothing to do with comments. Every edit operations may cause the freeze, if it occurs.

Yes, just noticed that. It happens in other places too.

[wmjordan]

@fitdev The recent beta should have fixed the performance issue. In beta 7359, the C# tagger subscribed events from Roslyn and the document change events would be fired. Once the event was fired, each document would reload the document model. More documents were opened, more reloading occurred. The reloading might result in CPU core starving.

Why it happened to you when you typed comment? It was because we usually type slow while we code, but much faster when we comment.

The recent beta suppressed background reloading of the taggers. Thus it should work Ok. I also enlarged the interval between document change and refresh.

[fitdev]

I see. Thank you for the explanation. Yes, in my solution I actually have like 10 windows open - each with 10+ documents, so overall I have at least 100 documents open in tabs - likely a bit more.

Highlight is now updated when external files have been changed

I hope it is not going to degrade performance in my case. I, for example am ok with highlight not being updated in the other documents when I type something in one. Perhaps, if it is an issue you could introduce an option that controls / turns off this behavior if performance becomes a problem. Or for example a document could get updated once it becomes active, i.e. you can maintain a "dirty" state for each inactive document which means that when it gets activated it should be updated (all the highlights reapplied). That way you can still auto-update highlights w/o reloading the document but do so only on demand - when it becomes active.

I will give the new beta version a try soon. Thank you for all your work!

[wmjordan]

for example a document could get updated once it becomes active, i.e. you can maintain a "dirty" state for each inactive document which means that when it gets activated it should be updated (all the highlights reapplied). That way you can still auto-update highlights w/o reloading the document but do so only on demand - when it becomes active.

Yes, the recent beta was behaving a bit like that.

[fitdev]

Suggestion: It would be nice (if it does not cost anything extra in terms of performance) to instead of just including lines of code for a given file / type / member, to display: total lines of text, lines of actual code, lines of comments (both doc and regular), lines of whitespace, and next to each number in () display % of total lines in a file / type / member.

[wmjordan]

Suggestion: It would be nice (if it does not cost anything extra in terms of performance) to instead of just including lines of code for a given file / type / member, to display: total lines of text, lines of actual code, lines of comments (both doc and regular), lines of whitespace, and next to each number in () display % of total lines in a file / type / member.

No, they are not provided as a piece of cake, except total lines of text.

[fitdev]

Oh I see. Still some kind overall statistics module for Codist may be a nice feature that would show various line, member, and type counts, filterable by project / namespace.