High CPU When Editing

[Scott Posey]

I'm getting very high CPU just doing simple editing of tests. This activates the fans on my laptop at full blast and is super un-fun.

Are there features I can turn off to lower the CPU?

What can I do to help debug this issue?

[Scott Wells]

Yeah, I've noticed this as well and it's my number 1 priority right now. I'm going to do some profiling this evening to see if I can figure out what's causing it. Ideally I'll just fix it, but worst case scenario I want to understand it so I can prescribe a workaround (e.g., disabling certain inspections) until I can produce a full fix. I'll keep you (and anyone else watching this) posted via comments on this bug.

[Scott Wells]

Scott, would you try something today? Please disable IC2's Unused Declaration code inspection and see if that helps. I profiled and tested for a few hours last night and that was the only thing that showed up with much of a presence. I can definitely see how that might contribute as it has to check for usages on-the-fly as you're typing. I have a number of optimizations already in place, but again, I could see that being a(/the?) contributor here. I'll be curious to know whether you see a difference with it disabled. Thanks!

[Scott Posey]

Thanks for the tip, I've disabled Unused Declaration Inspection for Salesforce only. I'll let you know how it goes.

[Scott Wells]

Thanks. Let me know. I did see a difference in my own casual testing, but I also wasn't seeing quite the CPU spikes you're describing...though I did see enough to make me want to investigate it for sure. I'll be interested to hear your findings.

[Scott Posey]

Thanks, that change makes the tool usable. I'm working with a codebase that's got around 200k lines not factored into nice new modules.

[Scott Wells]

Good to hear but "usable" is definitely not the word I want to hear. Sounds like on that code base the code inspections are adding significant overhead since that's the only major difference between IC2 and IC1 in terms of as-you-type behavior. I have a HUGE test project basically comprised of all the open source Apex I could find. Let me do some profiling and benchmarking against that and see if I can nail down where that overhead is coming from and address it. Thanks for the continued feedback!

[Scott Wells]

Delivered in 2.0.0.3. I implemented VERY aggressive caching of declaration reference tracking results for the Unused Declaration code inspection. I no longer see that inspection as an offender in profiling results during normal editing. Having said that, if you still see high CPU or performance lag while editing source, please let me know and I'll look into it.

[Scott Posey]

Thanks for the speedy response. I've been suffering from a deluge of marketing email and missed your update from the 27th.

I did see high CPU again with 2.0.0.3 and a new project with the Unused Declaration turned on for Salesforce, but it seems to be OK in 2.0.1.1.

[Scott Wells]

Gotcha. I'm hammering on it on a daily basis on my day job right now and haven't seen any major hiccups, but obviously my projects and yours are likely different enough to produce different results. Let me know if you do see issues against recent builds with (or worse, without) that inspection enabled.

[Nunzio Capasso]

Hello , i am still experiencing this.

without “unused declaration” on → https://kutt.it/saPotg

with unused declaration” on → https://kutt.it/q8wwwO

The class that i was using for the test is relative small to (180 lines).

Obviously this is not a big deal and i can just disable that inspection.

Pc spec : ryzen 2700u - 8bg ram

Thx,

Nunzio.

[Scott Wells]

Nunzio, is this a recent behavioral change after updating to 2019.2 by chance? If so, you may be experiencing this issue:

https://youtrack.jetbrains.com/issue/IDEA-219217

The fix--at least for me--was provided in this response:

https://youtrack.jetbrains.com/issue/IDEA-219217#focus=streamItem-27-3613574.0-0

If that's not the case...either you're not on 2019.2 or that doesn't resolve the issue for you...I'll likely need to gather diagnostic info from you.

[Nunzio Capasso]

Hello Scott ,

I am on the 2019.2 but (as far as i can remember) it's always been like that ,even in previous versions.

I also tried the fix suggested in the link above but didn't work for me.

Log attached below , lemme know if u need a more specific one.

Thx,

Nunzio.

[Scott Wells]

Hi, Nunzio. Do you mind adding the following to Help>Debug Log Settings (the leading # is important):

#com.illuminatedcloud.intellij.inspection.ApexUnusedDeclarationInspection

then reproduce the performance issue for a bit, and finally provide the resulting idea.log file? Thanks!

[Nunzio Capasso]

Hi Scott ,

here it is the new log

[Scott Wells]

Thanks for the log. I see a few things like this that certainly stand out:

2019-08-07 16:46:02,373 [ 120899]  DEBUG - pexUnusedDeclarationInspection -   Still seems to be unused. Checking for interesting usages in the usage scope. 
2019-08-07 16:46:02,373 [ 120899]  DEBUG - pexUnusedDeclarationInspection -     Running on-the-fly, so only looking for the first interesting usage. 
2019-08-07 16:46:07,764 [ 126290]  DEBUG - pexUnusedDeclarationInspection -     None found. 

Notice the 5 second jump between the second and third lines. To me that means that finding usages is quite expensive in this project. However, two things should be happening in the base IDE to mitigate that expense. First, it should be using a very efficient index. Second, the base IDE shouldn't let it run for that long before terminating the search and running it again later when things are more idle.

Because these are both managed by the base IDE--technically IC is just asking the base IDE to search its indices for registered usages--my best initial recommendations are as follows:

1. Make sure that you're running with sufficient memory in case this is due to thrashing against the maximum allowed heap for the host JVM. Use these docs and bump the maximum heap to the most you're comfortable using on your machine. I generally recommend a minimum of 2GB (-Xmx2048m) for JetBrains IDEs regardless of whether you're working with Salesforce via IC, Java, or whatever.
2. Rebuild ALL caches and indices to make sure they're as efficient and complete as they can be. You can do this via File>Invalidate Caches / Restart>Invalidate and Restart.

Let's see how things look after doing those.

[Nunzio Capasso]

Unfortunately i got the same results.

[Scott Wells]

Okay. What we'll likely need to do is see if we can get profiling info since these gaps in the logs are seemingly in places where IC just consults the base IDE. I know that 2019.2 has some new features for getting profiling data. I'm playing with it now to see how it works so I can provide you instructions on how to gather and provide it. More to come shortly...

[Scott Wells]

Okay, good. Please follow these instructions:

https://intellij-support.jetbrains.com/hc/en-us/articles/207241235#CPU_Snapshot_2019_2

Basically start profiling, try to constantly reproduce the performance issue for up to a minute or so, stop profiling, and then either attach the resulting snapshot here or email it to [e-mail]. I'll take a look and see what's happening under the hood.

[Nunzio Capasso]

ok, i just sent u an email with the requested snapshot.

PS: this time i noticed the the CPU didn’t spike to 100% on every test but it never got under 80% utilization.

[Scott Wells]

Nunzio, I may actually have a lead. Do any of these classes have a large number of constructors? In the provided CPU snapshot each time there's a CPU spike it's trying to find usages of constructors of otherwise unused classes. I'm attaching a new build that includes additional debug logging around this suspicion plus something that might help the IDE to short-circuit long-running usage searches for classes with large numbers of constructors.

You can install this build using Settings/Preferences>Plugins>Install plugin from disk (under the gear drop-down). No need to extract the attached archive...just download and install it.

Once installed, please try to reproduce the performance issue and attach the resulting idea.log either way. Thanks!

[Scott Wells]

Actually please install this build as it includes one other attempt to allow the IDE to short-circuit a long-running usage check based on another spike I saw in the CPU snapshot.

[Nunzio Capasso]

Thx Scott, i am going to install the second version and do some testing (and snapshot taking too) with and without the inspection on.

Regarding the class that i was testing one , i will send u a copy of that via email ( no secrets here ).