Why is IntelliJ 13 IDEA so slow after upgrading from version 12?

Question

While using IntelliJ 13 ultimate edition for a week, it just seems really slow.

First of all, the whole IDE stops for a second or so every once in a while. The Java editor's auto complete is really slow compared to 12 version.

I have not changed anything from the default settings other than using a Dracula theme.

It seems that this is not a problem of my own. Many people suggested setting the heap size higher than default, or clearing the cache, but I have not checked or tested on these suggestion. Do I need to change some setting to improve the new version's performance?

Answer 1

I had the same problem with slowness in IntelliJ 13 after upgrading from 12. What worked for me was editing the idea64.vmoptions in the bin folder and setting the max heap to 8 GB (was 512 MB) and the Max PermGen to at least 1GB (was 300MB).Example below:

-Xms128m
-Xmx8192m
-XX:MaxPermSize=1024m

Upon restart it was much faster.

For IntelliJ 2020 going back to 2017 on Mac /Applications/IntelliJ IDEA.app/Contents/bin/idea.vmoptions

On a Mac, this file is located in this path:

For IntelliJ 14 or 15 on Mac /Applications/IntelliJ IDEA 14.app/Contents/bin/idea.vmoptions

For IntelliJ 13 on Mac /Users/yourusername/Library/Preferences/IntelliJIdea13/idea.vmoptions

IntelliJ's updater (since 2017) seems to roll this change back, so you may need to re-apply it after updating.

On Ubuntu Linux, this file is located in this path relative to the install directory:

idea-IU-135.475/bin/idea64.vmoptions

and for 2016.2:

 ~/.IdeaIC2016.2/idea64.vmoptions

On Windows 10 (Community edition shown here) these files are located in:

C:\Program Files (x86)\JetBrains\IntelliJ IDEA Community Edition 2016.1.3\bin\idea64.exe.vmoptions

Answer 2

I noticed that disabling many of the plug ins really helps speed up IntelliJ. For example, I am not developing Android Applications. Turning the plugins related to Android development off speed up load time and makes the program run much smoother on my machine.

Answer 3

In my case, GIT integration appears to be causing the editor to be frustratingly slow with 13.

While typing, even comments, with GIT integration turned on, after about 30 characters, the UI freezes for a second or so. Its usually not long, but very annoying.

I am using GIT 1.7.8.0. Running on Windows 7 64 with a solid state drive and 12 gigs of ram and an intel I7 with 8 CPUs. I tried various things, like updating the idea64.exe.vmoptions to use more memory, like -Xmx2400m and -XX:MaxPermSize=2400m, -XX:ParallelGCThreads=6, but it didn't fix the problem.

The git repository is 1.3 gigs with 65,000 files.

I created a new "grails" project in a new git repository, and there is no issue. I created a new grails project in the existing large git repository, and intellij is slow. I turned off git integration by opening the project settings dialog and deleting the git root, and the problem goes away.

I tried disabling all of the GIT background operations through the 13 UI, but it didn't make a difference. I also tried both GIT built-in and native modes, and it made no difference.

In my case the workaround seems to be to disable GIT integration until I need it, and to then just re-add the git root. If anyone else can verify the same problem, then we might report it as an issue.

Answer 4

In my case massive performance degradation was caused by IntelliJ unintentionally using JDK/JRE 1.8. This seems to affect rendering performance quite badly and also leads to some unexpected crashes and deadlocks.

This would render the IDE unusable (latency of 1-2s on operations) for even a small ~3KLOC project.

Just ensure you are using JDK/JRE 1.7 when running intellij:

JAVA_HOME=/usr/lib/jvm/jdk1.7.0_67 intellij

(or whatever the equivalent is for your OS)

You can check the JRE that is being used to run intellij under Help -> About -> JRE.

Answer 5

Well I can't reply to Engineer Dollery's post above because I don't have 50 rep yet... but I've noticed the same thing. One problem has been reported already regarding hg4idea: http://youtrack.jetbrains.com/issue/IDEA-118529.

There't no fix yet except to disable the hg4idea plugin. But if that turns out to be your problem, vote for the bug!

Edit: JetBrains has fixed the bug in build IU-138-815!

Answer 6

I had a similar problem. In that case it was the Subversion plug-in. (Mac Mavericks, SVN version 1.7.10) Once I disabled this IntelliJ became useable again.

Got this from jstack:

"Change List Updater" daemon prio=2 tid=10df3f000 nid=0x12a421000 runnable [12a41f000]
   java.lang.Thread.State: RUNNABLE
    at java.util.Collections.unmodifiableList(Collections.java:1131)
    at com.intellij.execution.configurations.ParametersList.getList(ParametersList.java:88)
    at com.intellij.execution.configurations.GeneralCommandLine.getCommandLineString(GeneralCommandLine.java:210)
    at com.intellij.execution.configurations.GeneralCommandLine.getCommandLineString(GeneralCommandLine.java:189)
    at org.jetbrains.idea.svn.commandLine.CommandExecutor.createProcessHandler(CommandExecutor.java:186)
    at org.jetbrains.idea.svn.commandLine.CommandExecutor.start(CommandExecutor.java:137)
    - locked <76afcdfb8> (a java.lang.Object)
    at org.jetbrains.idea.svn.commandLine.CommandExecutor.run(CommandExecutor.java:262)
    at org.jetbrains.idea.svn.commandLine.CommandRuntime.runWithAuthenticationAttempt(CommandRuntime.java:62)
    at org.jetbrains.idea.svn.commandLine.CommandUtil.execute(CommandUtil.java:206)
    at org.jetbrains.idea.svn.commandLine.CommandUtil.execute(CommandUtil.java:189)
    at org.jetbrains.idea.svn.commandLine.SvnCommandLineInfoClient.execute(SvnCommandLineInfoClient.java:120)
    at org.jetbrains.idea.svn.commandLine.SvnCommandLineInfoClient.issueCommand(SvnCommandLineInfoClient.java:104)
    at org.jetbrains.idea.svn.commandLine.SvnCommandLineInfoClient.doInfo(SvnCommandLineInfoClient.java:90)
    at org.jetbrains.idea.svn.commandLine.SvnCommandLineInfoClient.doInfo(SvnCommandLineInfoClient.java:232)
    at org.jetbrains.idea.svn.commandLine.SvnCommandLineStatusClient.doStatus(SvnCommandLineStatusClient.java:106)
    at org.jetbrains.idea.svn.SvnRecursiveStatusWalker.go(SvnRecursiveStatusWalker.java:79)
    at org.jetbrains.idea.svn.SvnChangeProvider.getChanges(SvnChangeProvider.java:89)
    at com.intellij.openapi.vcs.changes.ChangeListManagerImpl.a(ChangeListManagerImpl.java:686)
    at com.intellij.openapi.vcs.changes.ChangeListManagerImpl.a(ChangeListManagerImpl.java:596)
    at com.intellij.openapi.vcs.changes.ChangeListManagerImpl.d(ChangeListManagerImpl.java:480)
    at com.intellij.openapi.vcs.changes.ChangeListManagerImpl.access$1100(ChangeListManagerImpl.java:71)
    at com.intellij.openapi.vcs.changes.ChangeListManagerImpl$ActualUpdater.run(ChangeListManagerImpl.java:387)
    at com.intellij.openapi.vcs.changes.UpdateRequestsQueue$MyRunnable.run(UpdateRequestsQueue.java:260)
    at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:439)
    at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)
    at java.util.concurrent.FutureTask.run(FutureTask.java:138)
    at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$301(ScheduledThreadPoolExecutor.java:98)
    at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:206)
    at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:895)
    at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:918)
    at java.lang.Thread.run(Thread.java:695)

---

other run:

"Change List Updater" daemon prio=2 tid=124556000 nid=0x129c7a000 runnable [129c78000]
   java.lang.Thread.State: RUNNABLE
    at java.io.UnixFileSystem.getBooleanAttributes0(Native Method)
    at java.io.UnixFileSystem.getBooleanAttributes(UnixFileSystem.java:228)
    at java.io.File.exists(File.java:733)
    at org.apache.xerces.parsers.SecuritySupport$7.run(Unknown Source)
    at java.security.AccessController.doPrivileged(Native Method)
    at org.apache.xerces.parsers.SecuritySupport.getFileExists(Unknown Source)
    at org.apache.xerces.parsers.ObjectFactory.createObject(Unknown Source)
    at org.apache.xerces.parsers.ObjectFactory.createObject(Unknown Source)
    at org.apache.xerces.parsers.SAXParser.<init>(Unknown Source)
    at org.apache.xerces.parsers.SAXParser.<init>(Unknown Source)
    at org.apache.xerces.jaxp.SAXParserImpl$JAXPSAXParser.<init>(Unknown Source)
    at org.apache.xerces.jaxp.SAXParserImpl.<init>(Unknown Source)
    at org.apache.xerces.jaxp.SAXParserFactoryImpl.newSAXParser(Unknown Source)
    at org.jetbrains.idea.svn.commandLine.SvnCommandLineStatusClient.parseResult(SvnCommandLineStatusClient.java:138)
    at org.jetbrains.idea.svn.commandLine.SvnCommandLineStatusClient.doStatus(SvnCommandLineStatusClient.java:118)
    at org.jetbrains.idea.svn.SvnRecursiveStatusWalker.go(SvnRecursiveStatusWalker.java:79)
    at org.jetbrains.idea.svn.SvnChangeProvider.getChanges(SvnChangeProvider.java:89)
    at com.intellij.openapi.vcs.changes.ChangeListManagerImpl.a(ChangeListManagerImpl.java:686)
    at com.intellij.openapi.vcs.changes.ChangeListManagerImpl.a(ChangeListManagerImpl.java:596)
    at com.intellij.openapi.vcs.changes.ChangeListManagerImpl.d(ChangeListManagerImpl.java:480)
    at com.intellij.openapi.vcs.changes.ChangeListManagerImpl.access$1100(ChangeListManagerImpl.java:71)
    at com.intellij.openapi.vcs.changes.ChangeListManagerImpl$ActualUpdater.run(ChangeListManagerImpl.java:387)
    at com.intellij.openapi.vcs.changes.UpdateRequestsQueue$MyRunnable.run(UpdateRequestsQueue.java:260)
    at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:439)
    at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)
    at java.util.concurrent.FutureTask.run(FutureTask.java:138)
    at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$301(ScheduledThreadPoolExecutor.java:98)
    at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:206)
    at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:895)
    at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:918)
    at java.lang.Thread.run(Thread.java:695)

Answer 7

Best experience with following options (idea64.exe.vmoptions):

    -server
    -Xms1g
    -Xmx3g
    -Xss16m
    -XX:NewRatio=3

    -XX:ReservedCodeCacheSize=240m
    -XX:+UseCompressedOops
    -XX:SoftRefLRUPolicyMSPerMB=50

    -XX:ParallelGCThreads=4
    -XX:+UseConcMarkSweepGC
    -XX:ConcGCThreads=4

    -XX:+CMSClassUnloadingEnabled
    -XX:+CMSParallelRemarkEnabled
    -XX:CMSInitiatingOccupancyFraction=65
    -XX:+CMSScavengeBeforeRemark
    -XX:+UseCMSInitiatingOccupancyOnly

    -XX:MaxTenuringThreshold=1
    -XX:SurvivorRatio=8
    -XX:+UseCodeCacheFlushing
    -XX:+AggressiveOpts
    -XX:-TraceClassUnloading
    -XX:+AlwaysPreTouch
    -XX:+TieredCompilation

    -Djava.net.preferIPv4Stack=true
    -Dsun.io.useCanonCaches=false
    -Djsse.enableSNIExtension=true
    -ea

Answer 8

75s -> 10s intellij startup. All I did was switch from using the default 32bit exe to using the 64bit exe.

Answer 9

For me the problem was a nodes_modules folder with more than thousand files. I had to mark the directory as excluded.

Also see this list of possible problems.

Answer 10

I am on 13.1, and I have found the following setting works wonders for me: IDE Settings --> Editor --> Autoreparse delay (ms), which I have set to 1500 (default is 300).

On a large project, the compiler and inspections would be constantly kicking off between interactions. The delay perhaps help to reduce heap pressure and generally make the whole experience a lot quicker. My cpu is a lot cooler as well, which probably helps.

Answer 11

I have solved my performance issues by switching to the 32 bit mode. It seems to be related with the JRE that IntelliJ runs with. It ships with a 32 bit 1.7 JRE which is used when starting idea.exe. If you start idea64.exe, it uses a 64 bit JRE installed on the system. In my case this was a 1.6 JDK (the one I use for development). This caused IntelliJ to be nearly unusable.

After installing a proper 64 bit 1.7 JDK everything was fine with the 64 bit mode, too.

See the answer on the IntelliJ Support web site.

Answer 12

In my case I am developing within Moodle which creates huge JS and CSS minified files. Once I excluded theses "cached" minified files from the project, InitelliJ ran normally again.

Answer 13

I had similar issues with a very slow start and heap issues, increasing VM did not make a huge difference, just delayed the inevitable, the fix for me was to invalidate the cache via File > InvalidateCaches/Restart.

https://www.jetbrains.com/help/idea/2016.1/cleaning-system-cache.html

Answer 14

I've been using 13 since early beta and I have no problems at all. Perhaps it's your specific settings. Maybe your project has grown over time and the memory you gave Idea originally isn't sufficient for it now? Try giving Idea more memory to work with: http://www.jetbrains.com/idea/webhelp/increasing-memory-heap.html (instructions on how to do that).

Answer 15

IntelliJ version 13 is markedly slower than the 12 version from my experience. There are a few ways to speed it up, like increasing the VM options for intelliJ. For eg. I'm using a maven project, and for that I increased the runner and importer options to 4GB . It made things much faster than before.

Answer 16

My particular case (Mac) was I edited the info.plist to use java 1.7* (for whatever reason), and it ran like an absolute dog.

Changed back to 1.6* and installed java 1.6, and it was fast.

Answer 17

I was facing sluggish performance with Intellij 2016.1(64-bit) and JDK 1.8(64-bit). I switched to

• 64 bit intellij
• 64 bit Java 8 as JAVA_HOME path (This is required to run 64-bit Intellij)
• 32 bit Java 8 as JDK to be used for Intellij projects (File -> Project Structure | Project Settings -> Project | Project SDK).

By this combination, now Intellij performance is quite OK.

Answer 18

Editing the idea.vmoptions file is only a temporary solution until the next product update. See the JetBrains help pages for a more permanent solution to setting these values via the vm settings - https://www.jetbrains.com/help/idea/tuning-the-ide.html

Answer 19

Increase heap size for the compiler. By default the value is 700m which is a way too small with increasing number of plugins.

At v2019.1 it located here:

Settings -> Build, Execution, Deployment -> Compiler -> Build process heap size (Mbytes)

After I put 4000 there it solved most my performance issues.

Answer 20

My particular case: I had a number of method breakpoints while I was running my code in debug mode, which made my intelliJ slow.