SlickEdit consuming 100% CPU, doing nothing

[tim_k]

I'm running 25.0.1.0, hotfix 6, but this started before I applied the hotfix.

If I have slickedit open, but no files or workspaces open, the CPU usage is <1%, as you'd expect. When I create a new blank file (still no workspace), CPU usage jumps to about 14%. If I open an existing VHDL file, CPU usage jumps to 80-100%, and the UI becomes very sluggish and unresponsive. If I open another VHDL file, the CPU usage pegs at 98-100%, and does not drop. Closing the files returns CPU usage to expected levels.

If I open SystemVerilog files, the CPU usage jumps to about 40%, and doesn't seem to increase with additional files opened.

With a workspace open the CPU usage is about the same, even allowing time for tagging etc to complete.

I just checked my linux box, and I'm also seeing similar behavior on RHEL7 with SE v 25.0.1.0, no hotfixes.

This is making SE virtually unusable. Any ideas?

Thanks,

-Tim

[Dennis]

Try this command (run from the Slick-C command line):   codehelp-update-context-stats

[patrick]

EDIT: I somehow didn't see Dennis' post when I posted this.  Definitely try his suggestion first. 

I don't see this with or without the hotfix with verilog or system verilog files.  Will just any file will do it, or are certain files worse than others?  Does it make any difference if you start SlickEdit with a clean config using the -sc command line option?   

It might help to get a Slick-C profile.  Open up a problem file in SlickEdit, go to the Slick-C command line and type in "profile start".  Let the editor sit and spin for a couple of minutes to gather data.  Then run "profile stop", and then "profile save" to save it out to a .tsv file you can post for us.

[tim_k]

It's definitely related to syntax coloring. Verilog and SystemVerilog files don't do it. With a single VHDL file open, and no workspace open SlickEdit was taking 55% of CPU cycles. I've noticed that after a few minutes of inactivity, with the VHDL file open, the CPU usage drops back to normal. As soon as I enter a single character in the file, CPU usage jumps back to 100%

I ran the codehelp-update-context-stats and got attached image (filenames removed). I closed the VHDL file and ran it again, with the same results. When I closed the VHDL file, the CPU usage dropped to below 5%.

I tried running with and without the -sc option and there was no difference in behavior.

In the .tsv file I've attached, I started profiling with nothing open and <5% CPU usage, then opened the VHD file and did nothing else. CPU usage jumped to 99%. I left there for a few minutes thinking it might drop back down, but it did not. I then closed the VHD file, and CPU usage dropped back to <5%. Then I stopped profiling.

Thanks,
-Tim

[Dennis]

Looks like the time is being spent in Symbol Coloring.  I would suggest turning off Symbol Coloring (View > Symbol Coloring > uncheck Enable Symbol Coloring).  SlickEdit will remember this per-file.

If you can submit (here, or to send in to support), a source file that exhibits these performance issues, we could see if anything could be optimized.  I see that a lot of time is being spent in code for parsing record initializers, but I need a specific test case to reproduce it and know the problem is (or can be) fixed.

[tim_k]

Enable symbol coloring is not sticky. I can disable it as you describe, but after closing/reopening the file symbol coloring is enabled again. Quitting/reopening SlickEdit doesn't make a difference. Saving the file with symbol coloring disabled doesn't help either.

I've attached a stripped-down test file that causes the issue, but not as severely. The CPU usage goes up to about 50% when it's opened. Here's what I've observed when playing around with the attached test file:

Opening it causes CPU usage to jump to about 50%.
Disabling symbol coloring and doing nothing else does not affect CPU usage.
With symbol coloring enabled, and having done nothing since opening the file, if I enter a character anywhere in the file, CPU usage drops to normal. After deleting the character (with backspace, or undo) or reverting the file, CPU usage stays low.
With symbol coloring enabled, and having done nothing since opening the file, if I delete a character anywhere in the file, CPU usage drops to normal. After reverting the file (with undo or revert), the CPU usage stays low.
With symbol coloring enabled and doing nothing since opening the file, if I scroll 2+ lines from the top CPU usage drops to normal.
With symbol coloring enabled, and doing nothing since opening the file, if I disable the minimap, CPU usage drops to normal. When I re-enable the minimap, CPU usage jumps back to ~50%
If I do any of the above steps that result in a drop in CPU usage, then disable/enable the minimap, CPU usage jumps back to ~50%

A real file takes 100% of CPU on launch, and drops to normal when disabling the minimap. Re-enabling the minimap brings the CPU usage to about 50%. Scrolling drops CPU usage to normal. This does not seem to be the case when I have a normal working set of files open, as the CPU never drops even with scrolling. I have not tried disabling the minimap of a normal working set of files.

-Tim

[Dennis]

Are you sure you attached the right test file?  Symbol coloring is nearly instant with that file on my machine.

I, however, do not have the same workspace, so perhaps the issue is looking up symbols under "IEEE" or "work", but that would not jive with the profiling data you sent me.

Could you profile just turning Symbol Coloring on and off in that test file?

[tim_k]

Visually, syntax coloring is nearly instant in that file. It's just consuming a ton of CPU.

During the attached .tsv, I had the test file open, using ~40% CPU. I disabled symbol coloring, waited a bit, then re enabled it. CPU usage did not change.
What are your thoughts on the effects of the minimap toggle?

-Tim

[Dennis]

Symbol coloring first colors visible lines, then a certain number of surrounding lines.  When the minimap is enabled, it extends the boundary to the lines visible in the minimap.  That is what explains the difference in performance, it has more work to do.  The next release will have an option to disable Symbol Coloring in the minimap.

The profile shows that for that sample file Symbol Coloring consumed maybe 1/5 second.  You can't expect it to look up every symbol in the file without at least some compute involved.  Definitely need a different file to pin down the hard case that gave you the original problem.

[tim_k]

Maybe there's some confusion. The issue isn't that it's taking a long time to do the symbol/syntax coloring (it isn't really). it's that the 100% CPU usage renders the entire application extremely sluggish, to the point of becoming barely usable.

I just tried working with a larger VHDL file, and the problem was definitely worse. I then switched to a workspace (this has all been without a workspace open) that is SystemVerilog based, and had 6 files open (5 SystemVerilog, 1 TCL). CPU usage jumped to 116%, and stayed there (as soon as I saw the CPU usage, I started profiling. File attached.). The minimap refused to give me the magnification popup for a couple of minutes. I clicked through all the file tabs, with the same result for each one. At one point I clicked to a file and the minimap refused to draw at all - just a gray box where it should've been. As I type this, SE is in the background consuming 70-90% of CPU. There's an SV file in the foreground, and all the syntax coloring is done in both the main window and the visible minimap.

After a bit more playing around, it's clear something is amiss with the minimap. In the same SV project with a small file in the foreground (one of the original 6) that fits entirely within the minimap, the magnified view of the minimap refused do draw for about 40 seconds. I was alternating between moving the mouse in the minimap area and letting it sit. Eventually the wait cursor (black & white circle) popped up for a brief period, then the magnified display appeared, and worked fine. The CPU usage during this was <5% (i didn't notice when it dropped, but I had been testing the Linux side for a few minutes, then returned to the Mac). Unfortunately, profiling was not on.

The larger VHDL file I used is from OpenCores https://opencores.org/websvn/filedetails?repname=udp_ip_stack&path=%2Fudp_ip_stack%2Ftrunk%2Frtl%2Fvhdl%2Farp.vhd, and is attached.

-Tim

[Dennis]

Do you only see minimap performance issues when Symbol Coloring is enabled?

No confusion.  There are numerous symbol coloring performance settings under Tools > Options... > Editing > Context Tagging(R) > Symbol coloring performance.  In your case, I would decrease the timeout, maybe something like 250ms, and set the number of lines above and below to 0, and set "Windows to color" to "Current Window".

Or just go to Document > VHDL Options... > View and turn off Symbol Coloring entirely.  I believe it is a great tool for visualizing more details about your code, but not at the expense of the performance getting in your way.

I will check out those sample files.  Thank you for the link to the other source code to test.

[tim_k]

Yes, just turning on the minimap drives CPU usage high, with symbol coloring turned off.

Just to be sure there wasn't anything in the configuration causing issues, I moved the <userName>/Library/Application Support/SlickEdit directory and relaunched, getting the stock config. Changing nothing in the config, opening the arp.vhd file causes the CPU usage to jump. The config has symbol coloring off, and the minimap on. The default size on launch was small on my 4k monitor, so I expanded it. Changing the window size without changing anything else causes the CPU usage to increase/decrease with the size of the window. Further experimentation shows that it's the vertical size of the editor window, and specifically how much of the file is shown in the minimap. The less minimap, the lower the CPU usage. The same holds true if I zoom/unzoom the minimap itself. The less of the file displayed in the minimap, the lower the CPU usage.

All of this has been on the Mac side. It's more difficult to reproduce on the Linux side, but it does exhibit similar behavior when I'm able to reproduce it. I suspect the reproducibility issue may be because the Linux side is running on a server class machine that is substantially more capable than my Mac.

-Tim

[Dennis]

Try right-clicking in the minimap and turning on "Delayed minimap updating for faster scrolling".  That should be enabled by default on macOS.  You can also try turning off anti-aliasing for the minimap.

Could you provide your "Apple > About this Mac" information to give me an idea of the kind of hardware you are working with?

[tim_k]

Delayed updating is on, and i turned off anti-aliasing to no effect.

About this Mac:
MacOS v11.2.3
MacBook Pro 15", 2017
CPU - 2.8GHz quad core i7
16GB memory
Intel HD Graphics 630 1536MB

[Clark]

Here's an installer that should fix the minimap performance problem you are seeing:

https://support.slickedit.com/outbound/2501/2021-04-21/se_25000100_mac.dmg

Let us know how this works for you. We didn't have an old MacBook Pro to test it on but this performance should be significantly better.