SE performance with many buffers open

[rjpontefract]

Hi.  I'm running SE 27.0.1.0 with HF 5 on Windows 10.  I've noticed that SE slows down and has noticeable pauses when I have many (~100) buffers open containing mostly C source files, but some XML and TXT files.  Scrolling can be laggy and there can be a short pause between moving the mouse wheel a notch and the buffer scrolling.  If I close buffers and have ~15 open then SE is much more responsive.
Running the Slick-C profiler shows that _as_callback in autosave.e seems to be using the most time.  I have autosave turned off however, so is this normal?
Is there anything you can recommend to restore SE performance when a large number of buffers are open?

[Dennis]

Could you post your profiling results (Macro > Slick-C Profiler > Save...)?  Also, are you using Symbol Coloring?  There are some options to limit how many buffers Symbol Coloring tries to keep up-to-date (Tools > Options... > Editing > Context Tagging > Symbol Coloring performance > Windows to color.

[rjpontefract]

Hi Dennis

I've attached the profiling results as requested.  I do have symbol colouring enabled and it's currently set to "All visible windows".  I only have one window open and one buffer visible, does that mean it's only working on that one buffer?

[Dennis]

Are those profiling numbers with just the one window?  They look pretty normal.  How long were you running profiling for?  When you have lots of buffers open, if things seem laggy again, you could try switching it to current window only.

[rjpontefract]

Hi Dennis, thanks for the info.  I only ran profiling for 30 seconds or so.  I'll switch it to current window only and, if it happens again, I'll get some more profiling data for you.

[rjpontefract]

I ran into the same performance issues today and I got some more profiling data.  I then changed the symbol colouring scope to "current window" and saw no change in behaviour.  I ran the profile again and have attached both lots of profiling data.  Is there anything else I can get for you?

The main symptom of this issue is around a 500ms to 1s delay between moving the mouse wheel and the buffer content scrolling.  If I the scroll continuously there is no delay.  If I stop scrolling and move the scroll wheel again, I'm back to the delay.  Are there any other options that might affect this?

[Dennis]

There are a number of performance options under Tools > Options... > Editing > Context Tagging > Symbol Coloring performance.

You could try:

1) INCREASING "Update after ..."
2) DECREASING "Timeout after ..."
3) DECREASING "Number of lines to color above and below ..."
4) DECREASING "Number of off-page lines ..."

Try 2000, 250, 20, 10.

It will not be as responsive as you are scrolling, but that is to be expected.

You are also seeing a significant amount of delay from Live Diff (1.7 seconds), you can also push Live Diff out further by increasing Tools > Options... > Version Control > Live Diff > "Amount of idle time ...", and decreasing "Live Diff file size limit".  I use the icon on the Version Control tool bar to toggle Live Diff on demand rather than keeping it on all them time.  (It's the icon that looks like a broadcast antenna -- think of it as "Live, from SlickEdit, it's Wednesday Morning Diff!!!")

I can see by looking at the profiling results that "Current Window" cut down the total amount of time spent in symbol coloring significantly (as it should).  Also, if you look at the profiling results, and sort decreasing by "Max Time" (function), the bit "hits" over 1/2 second are coming from Live Diff.

[rjpontefract]

Thanks Dennis, I've turned off live-diff and adjusted the symbol colouring options as you suggested.  It seems good at the moment, so I'll see how it goes.

[rjpontefract]

I'm not sure if it's related to the parameter changes but SE has just gone unresponsive and is burning a whole CPU core.  It stayed that way for around 10 minutes before recovering.  Could those changes have caused this?

[Dennis]

Unlikely that the settings caused that. 

There is a command you can run from the SlickEdit command line you could try to see if anything stood out taking a long time to tag: 
codehelp-update-context-stats

The symbol coloring has timeouts, so it's unlikely to grind for 10 minutes, however, there are difficult cases with multiple levels of type inference, template expansion, and class inheritance, where the amount of computation to evaluate the type of a symbol gets, well, silly.  So, in some of those cases, it can exceed the timeout by a small amount, but not 10 minutes, that is very unlikely.

[rjpontefract]

Thanks Dennis.   I tried the codehelp-update-context-stats command and nothing stood out, but I'll try it again if the problem recurs.

I'll also update to 27.0.2.0 when I get the chance, as this item from the release notes may be relevant:

Fix for temporary hang when switch application focus back to SlickEdit when have large Visual Studio solution open.