Linqpad Intellisense very slow
Linqpad intellisense on my Win 10 laptop has been extremely slow for me recently. I just installed the latest beta v5.33.09 (AnyCPU) in the hopes that it would resolve the issue, but to no avail.
I mostly use LinqPad as a scratchpad to test small pieces of code or expressions. There are no database connections being made. I'm simply running the "C# Program" profile. When I write "var" to start my first line of code, the intellisense kicks off and just hangs there for a few seconds. It's making this product quite unusable.
Any recommendations as to what I should do to help resolve this? I've never encountered this in previous iterations.
I mostly use LinqPad as a scratchpad to test small pieces of code or expressions. There are no database connections being made. I'm simply running the "C# Program" profile. When I write "var" to start my first line of code, the intellisense kicks off and just hangs there for a few seconds. It's making this product quite unusable.
Any recommendations as to what I should do to help resolve this? I've never encountered this in previous iterations.
Comments
Go to Help | About and click "Start internal profiling". Then create a query, type "var" or whatever causes it to hang, go back to Help | About, and click the link again to stop profiling and display the file containing the results. Could you please send me the file (support at linq pad dot net).
Thanks!
And can you reproduce it on another machine?
I'm using a MS Surface Pro 4, Core i7-6650U model with Surface Hub into which I connect an HD monitor and a 4k monitor (running at 150% scale).
I first started experiencing graphical weirdness after one of the larger recent windows updates, a few months ago, roughly when Meltdown and Spectre were in the news.
The problem in LINQPad is as described by cabraham except I type "Dim x" (which takes >10sec). I've also experienced similar weirdness in Excel and Tortoise SVN.
Here's the weird part. As soon as I disconnect my 4k monitor all the problems disappear, I don't even have to restart my LINQPad. As soon as I reconnect it the problem begins. It doesn't seem to matter which screen LINQPad is running on.
This is clearly a windows problem, probably GDI or DWM. I'll send perf logs in a moment.
I've dug through the syntax editor source code and have identified a bug in not disposing a GDI+ pen. There's a small chance that it's related to this - if so, you'll find it fixed in the 5.33.11 beta. It's worth a try; otherwise as you say, it will be something inside Windows which will be hard to track down.
The version I tried earlier when I sent the perf logs was also 5.33.11 - did you update it but kept the version the same? Anyway, I redownloaded 5.33.11 AnyCpu, unfortunately the problem persists. For now I'm working around the problem by switching off "Show completion list after typing a letter" and using Ctrl+Space when I need it. Hopefully one of the coming windows updates will resolve this.
PS: LinqPad is my bread and butter and I insist that everyone I work with install it, thank you for this little gem.
I have LinqPad installed on my Dell XPS 15 9570.
I have 2 external displays.
1x 1080p HDMI
1x 2k USB-C to DisplayPort
When I use LinqPad without any external displays everything works fine.
When I plug in only the 1080p screen, everything works fine.
When I plug in only the 2k screen, everything works fine.
But... when I plug in both the 1080p screen and 2k screen I experience the massive autocomplete lagginess to the point where LinqPad isn't really usable anymore.
I'm not saying this is an issue with LinqPad - I just wanted to report the details I've found in trying to diagnose this issue.
I hope this is helpful to someone. For now I think i'll unplug my 1080p screen when I want to use LinqPad.
https://www.linqpad.net/download.aspx#beta
Thanks Joe. See attached file. I was just typing in the editor, characters stopped being echoed and had a spinning cursor for 10+ seconds. The last keys I typed never echoed when I got a cursor back.
Hi Joe,
This seems to be happening to me as well - Both on LINQPad5 & 6. I'm on WIN10 on a Surface book 2.
I'm unable to reproduce when exactly this happens, but the next time it does, I'll send across a profiling file to the email address mentioned in this thread.
Thanks for your efforts.
Does this happen only with certain queries, or with any query? And if it's only with certain queries, how many assemblies does your query reference? And where are they coming from? Are they from a network share or are they NuGet references?
Sure, that would be helpful. Also if it's query-dependent and you're able to share the query (Ctrl+Shift+U), that would help.
Hi @JoeAlbahari,
Happens with every query I've tried. Simple query probably references 4 or 5 of my own vb.net (3.5) assembly that are included by default by not used by the query. They are located on the local drive of my Amazon workspace. LinqPad has been workng fine on this platform for at least a year until recently. Intellisense is just killing it and it's unusable now.
The log indicates that the machine is running very slowly. Operations that should be virtually instant, such as Array.Copy, are taking significant time to execute. I would suspect that something has changed in your Amazon workspace that is creating a low memory or poor CPU performance condition.
When this problem occurs, are you able to run a performance profiler on the virtual machine?
Hi @JoeAlbahari,
Just to clarify, it's not the execution of the queries that is slow but the editing and intellisense. The queries actually run as fast as usual, but the editing is unusable. Key strokes stop echoing and get lost if keyed ahead. Also F12 to reflect method info has also started failing with filename/path too long error (but I assume that's a different issue).
I should chime in here to say that while it doesn't happen very often, when it does, it gets pretty bad. It took a while for it to manifest in v6 for me but it's here now and it's not great.
It could take anywhere from 0.5-5+ seconds just for a keystroke to register and output the character in the editor or the cursor to move. Even just selecting text with the mouse or keyboard is noticeably slow. Before it used to take a while after having the same file open for a while (i.e., days) but I'm now getting it more sooner (~30min or so open) with this script I'm working on now. Usually closing and reopening the script will get things back to normal, but it will come back inevitably.
Doesn't look the profiling option is not in 6. Task manager doesn't show any spikes. Everything else seems fine, all other apps are responsive. Any other way to help diagnose this issue?
Unfortunately, .NET Core doesn't have the ability to self-profile like .NET Framework.
When this occurs, does the private working set peak by any chance?
I'll have to try again when it's running slow again, it's running relatively normal right now. But I've seen the private working set hover around 540MB when I last checked, now it's sitting at 488MB. Does this sound high to you?
Hi @JoeAlbahari,
Sorry, reposting this comment (from 17 Dec 19) as I don't think i got a response...
Just to clarify, it's not the execution of the queries that is slow but the editing and intellisense. The queries actually run as fast as usual, but the editing is unusable. Key strokes stop echoing and get lost if keyed ahead. Also F12 to reflect method info has also started failing with filename/path too long error (but I assume that's a different issue).
I think we're all on the same page @coqqy.
It's starting to bog down pretty bad for me but isn't at its worst yet. Private set is at ~1.1GB.
Are you able to confirm that the performance problems correlated to memory consumption? Is it the same for you, @coqqy?
It does seem to be the case. Closing the problem query and reopening it drops instantly to ~300MB and it seems back to normal. In general, the longer the query is open and in active use, the sooner this happens.
@coqqy - is this the same for you? I want to establish whether your problem is the same or different.
@JoeAlbahari , @JeffMercado,
I don't see much change in memory consumption.
I only had one query open, but from the start, as I was entering the code, there was significant delay for keystrokes to be echoed. Just now I typed a bit more and LinqPad just froze with a spinning icon and no keystrokes echoed. Fyi, I'm using LinqPad5.