I'm pretty sure your problem is different to Jeff's, and most likely related to the environment. The log strongly indicates that the issue is not caused by a bug in LINQPad.
@JeffMercado - what you describe implies a (kind of) memory leak. Are you able to give me a series of steps to reproduce this? I've tried monitoring memory consumption during editor activity with an ordinary query and cannot produce any leak, so it must require something special.
I don't think I'm doing anything particularly special, just editing a fairly large script with several other decently sized scripts included and have LINQPad running for long sessions (days). Utilizes all the latest C# and LINQPad features (async/await, asyncenumerable, readonly properies, expression-bodied members, nullable reference types, namespaces within scripts, etc.). The one I notice this the most is essentially an asynchronous console app to automate some tasks within TFVC and syncs to a local git repository making heavy use of async/await and some web apis.
I tried monitoring the memory usage as I edited and it seems to increase more rapidly as I mouse over different symbols, use autocompletion (Ctrl + Space), and just use the editor in general. This all goes away when I close the affected script and reopen.
Some other anomalies I notice that may or may not matter here involve the way the intellisense either shows the items or what it chooses to show. It looks like there's no distinction for nullable reference types when the type is shown (i.e., a variable of type string? is displayed as string). When using an object initializer as arguments to a method call, LINQPad can't figure out what intellisense to show at times, depending on where the caret is located. Sometimes it will show the parameter intellisense info, other times it will show the member names of the object being initialized, otherwise it would do neither and just show all names in scope.
Note this also occurred in v5 as well, only this is happening way more frequently this time around with a completely new set of scripts.
I tried monitoring the memory usage as I edited and it seems to increase more rapidly as I mouse over different symbols, use autocompletion (Ctrl + Space), and just use the editor in general.
Sorry, I should have pointed out that you need to initiate a GC before knowing whether more memory has genuinely been consumed. You can do this by pressing Shift+Alt+G. (This triggers a GC in both the current query and the host process.)
Tried garbage collecting in the script and it is not making a dent. Memory usage by LINQPad is sitting at 2GB. I have two scripts open for over a day, the main script (~600 lines, major changes, having the slowness) and one of it's loaded scripts (~400 lines, minor changes, not having the slowness)
I know this is a very old thread, but I was struggling with these same problems (in V5, V6, V7). After a lot of troubleshooting, I found out that in all of my LP scripts where this slowness/stuttering of intellisense/autocomplete occurred, I imported the Microsoft.Graph namespace, which is huge with a lot of types. After removing the namespace import, and just using the full type paths instead (eg. Microsoft.Graph.GraphServiceClient), the intellisense slowness/stuttering stopped, and everything went to normal again.
@jordanab54 said:
I know this is a very old thread, but I was struggling with these same problems (in V5, V6, V7). After a lot of troubleshooting, I found out that in all of my LP scripts where this slowness/stuttering of intellisense/autocomplete occurred, I imported the Microsoft.Graph namespace, which is huge with a lot of types. After removing the namespace import, and just using the full type paths instead (eg. Microsoft.Graph.GraphServiceClient), the intellisense slowness/stuttering stopped, and everything went to normal again.
@JoeAlbahari I just had the same issue with Microsoft.Graph.GraphServiceClient this make intellisense very slow.
Thanks - I've managed to repo it on a laptop. It's the Windows listbox itself that's the culprit - it doesn't work well with 14k items. I will release a workaround soon that will more aggressively filter in that scenario, making the delay when typing will much less noticeable.
FWIW, I tried to repro but doesn't happen for me as badly. There is a noticeable pause when intellisense loads up but I guess that's to be expected since the Microsoft.Graph namespace has a lot of types. And this happens on all uses of intellisense afterwards. Are there any options for improving perf for this? Like caching and displaying some set and maybe scrolling around would load more.
I've added a further workaround to 7.6.4. LINQPad now keeps track of how long it takes for the popup to appear, and if it exceeds a threshold, prevents an open listing from automatically appearing again for that query.
I upgraded CPUs on my Dell Precision T7810 (from 2x E5-2680v3 to 2x E5-2697Av4) and now LINQPad is abnormally slow. It takes about a second between pressing a key on keyboard and when character appears on the screen. That's not normal. I had to reenter my serial key after CPUs replacement. I have no idea why LINQPad is so slow. I reinstalled it, but that did not help at all. I can't use it any more. Did I get too many CPU cores? Right now I have 32 cores / 64 threads.
Does this occur with all queries? And if you start LINQPad and immediately start typing, is it slow then?
Also, can you try running LINQPad 5 (to determine whether the problem also occurs with .NET Framework). And if it does, could you please go to Help | About and click "Start internal profiling" to collect performance data.
This happens because the line of code that initializes the array has 418,000 columns! FWIW, Visual Studio's editor grinds to a halt, too, with that line of code.
You have a couple of options for workarounds. One is to read in the data in from a text file. Another is to #load the data in from another query. To do this, create a query called "data.linq":
void Main()
{
}
class Data
{
public static int[] Height = new[] { 8361, 5302, 8672, 2400, 5150, .... }
}
Then from another query:
#load "data"
int result = Solution.MaxArea (Data.Height);
result.Dump ("Result");
Console.WriteLine (result == 705634720);
public class Solution
{
...
}
Yes, the editor is painfully slow for me in VS2022 with the following program:
// See https://aka.ms/new-console-template for more information
Console.WriteLine("Hello, World!");
int[] height = new[] { 8361, 5302, ........................................... 853 }; // truncated for forum
int result = Solution.MaxArea(height);
Console.WriteLine(result == 705634720);
Generally speaking, when the source file size gets large (at least a couple 100k), then the analyzers and compilers will struggle to try to process it as it's edited in real time. So unless your data is reasonably sized, it probably should not live in your source file. Either store it externally or generate it if possible.
As an alternative, perhaps you could make use of Util.LoadString() and Util.SaveString() (or LoadBytes/SaveBytes) to store serialized versions of your data and load it that way. They're backed by files in the end so it should persist across calls.
Comments
I'm pretty sure your problem is different to Jeff's, and most likely related to the environment. The log strongly indicates that the issue is not caused by a bug in LINQPad.
@JeffMercado - what you describe implies a (kind of) memory leak. Are you able to give me a series of steps to reproduce this? I've tried monitoring memory consumption during editor activity with an ordinary query and cannot produce any leak, so it must require something special.
I don't think I'm doing anything particularly special, just editing a fairly large script with several other decently sized scripts included and have LINQPad running for long sessions (days). Utilizes all the latest C# and LINQPad features (async/await, asyncenumerable, readonly properies, expression-bodied members, nullable reference types, namespaces within scripts, etc.). The one I notice this the most is essentially an asynchronous console app to automate some tasks within TFVC and syncs to a local git repository making heavy use of async/await and some web apis.
I tried monitoring the memory usage as I edited and it seems to increase more rapidly as I mouse over different symbols, use autocompletion (Ctrl + Space), and just use the editor in general. This all goes away when I close the affected script and reopen.
Some other anomalies I notice that may or may not matter here involve the way the intellisense either shows the items or what it chooses to show. It looks like there's no distinction for nullable reference types when the type is shown (i.e., a variable of type
string?is displayed asstring). When using an object initializer as arguments to a method call, LINQPad can't figure out what intellisense to show at times, depending on where the caret is located. Sometimes it will show the parameter intellisense info, other times it will show the member names of the object being initialized, otherwise it would do neither and just show all names in scope.Note this also occurred in v5 as well, only this is happening way more frequently this time around with a completely new set of scripts.
Sorry, I should have pointed out that you need to initiate a GC before knowing whether more memory has genuinely been consumed. You can do this by pressing Shift+Alt+G. (This triggers a GC in both the current query and the host process.)
I'll be sure to do that and report my findings here.
Tried garbage collecting in the script and it is not making a dent. Memory usage by LINQPad is sitting at 2GB. I have two scripts open for over a day, the main script (~600 lines, major changes, having the slowness) and one of it's loaded scripts (~400 lines, minor changes, not having the slowness)
I know this is a very old thread, but I was struggling with these same problems (in V5, V6, V7). After a lot of troubleshooting, I found out that in all of my LP scripts where this slowness/stuttering of intellisense/autocomplete occurred, I imported the Microsoft.Graph namespace, which is huge with a lot of types. After removing the namespace import, and just using the full type paths instead (eg. Microsoft.Graph.GraphServiceClient), the intellisense slowness/stuttering stopped, and everything went to normal again.
@JoeAlbahari I just had the same issue with Microsoft.Graph.GraphServiceClient this make intellisense very slow.
Can you provide an example of a script that causes this problem?
To reproduce the issue here are the steps :
Create a new C# program
void Main() { }Just type the following line :
var dt = new DateTime();Everything works fine, now add this nuget package
Microsoft.GraphUnder var dt start type this
GraphServiceClientadd the namespace to the query then continue typing to have this lineGraphServiceClient client = new GraphServiceClient(You should have issue as soon as you start typing
newThanks - I've managed to repo it on a laptop. It's the Windows listbox itself that's the culprit - it doesn't work well with 14k items. I will release a workaround soon that will more aggressively filter in that scenario, making the delay when typing will much less noticeable.
Try 7.6.3 and let me know how you get along:
https://www.linqpad.net/linqpad7.aspx#beta
The issue is still present after typing
newis ok, but as soon as you start typingGrit is stuck.That's many times slower than I can reproduce... is there anything unusual about your hardware or environment?
FWIW, I tried to repro but doesn't happen for me as badly. There is a noticeable pause when intellisense loads up but I guess that's to be expected since the
Microsoft.Graphnamespace has a lot of types. And this happens on all uses of intellisense afterwards. Are there any options for improving perf for this? Like caching and displaying some set and maybe scrolling around would load more.I tried to reproduce with 7.5.15 (x64) and have no issues - intellisense after starting to type new is snappy and fast.
Nothing special, it's a dell xps-15, intel 12th gen i9-12900HK and 64GB of ram, default antivirus...
According to the last comments, the issue seems to come from my machine... Is there anything I can do to do some troubleshooting on my side ?
I've added a further workaround to 7.6.4. LINQPad now keeps track of how long it takes for the popup to appear, and if it exceeds a threshold, prevents an open listing from automatically appearing again for that query.
Joe,
I upgraded CPUs on my Dell Precision T7810 (from 2x E5-2680v3 to 2x E5-2697Av4) and now LINQPad is abnormally slow. It takes about a second between pressing a key on keyboard and when character appears on the screen. That's not normal. I had to reenter my serial key after CPUs replacement. I have no idea why LINQPad is so slow. I reinstalled it, but that did not help at all. I can't use it any more. Did I get too many CPU cores? Right now I have 32 cores / 64 threads.
Sergey
Does this occur with all queries? And if you start LINQPad and immediately start typing, is it slow then?
Also, can you try running LINQPad 5 (to determine whether the problem also occurs with .NET Framework). And if it does, could you please go to Help | About and click "Start internal profiling" to collect performance data.
Joe, looks like it's a query related issue and both versions of LINQPad (5 & 7) have it. I attached a sample query that makes LINQPad very slow.
This happens because the line of code that initializes the array has 418,000 columns! FWIW, Visual Studio's editor grinds to a halt, too, with that line of code.
You have a couple of options for workarounds. One is to read in the data in from a text file. Another is to #load the data in from another query. To do this, create a query called "data.linq":
void Main() { } class Data { public static int[] Height = new[] { 8361, 5302, 8672, 2400, 5150, .... } }Then from another query:
#load "data" int result = Solution.MaxArea (Data.Height); result.Dump ("Result"); Console.WriteLine (result == 705634720); public class Solution { ... }Thank you for suggested workarounds. BTW, I tried the same code in VS2022 and VS Code and did not notice any problems. Did you?
Yes, the editor is painfully slow for me in VS2022 with the following program:
// See https://aka.ms/new-console-template for more information Console.WriteLine("Hello, World!"); int[] height = new[] { 8361, 5302, ........................................... 853 }; // truncated for forum int result = Solution.MaxArea(height); Console.WriteLine(result == 705634720);Generally speaking, when the source file size gets large (at least a couple 100k), then the analyzers and compilers will struggle to try to process it as it's edited in real time. So unless your data is reasonably sized, it probably should not live in your source file. Either store it externally or generate it if possible.
As an alternative, perhaps you could make use of
Util.LoadString()andUtil.SaveString()(or LoadBytes/SaveBytes) to store serialized versions of your data and load it that way. They're backed by files in the end so it should persist across calls.