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?

I had a similar issue in 11 and 12, and determined that, for some reason, the java process on which IntelliJ was running was pinging my CPU pretty hard (all cores to 100%) for a couple of seconds every few minutes or so. I didn't really have the time or motivation to track down the root problem, so I forced the core affinity for IntelliJ to be only some of my cores. On Linux, I did this for the entire java binary (because it was easy with `taskset`). For Windows, I made a shortcut that starts IntelliJ's `exe` with the desired affinity. Not posting as an answer because I don't yet have 13. — ajp15243, Dec 12 '13 at 14:53
I suggest you check the JVM parameters of intellij. The default setup has heap size around 512MB, which is inadequate if you are working with relatively large projects. Check this answer http://stackoverflow.com/q/8581501/842860 — stackoverflower, Mar 10 '14 at 15:57
if you keep running into reproducable performance problems, please report them as described here: https://intellij-support.jetbrains.com/entries/29983118-Reporting-performance-problems Thanks in advance! — Yann Cébron, Mar 11 '14 at 19:02
Now that I think of it, the heap size might have been the problem. However, the fact that IntelliJ 12 with default settings works fine still remains. I've not used IntelliJ 13 for quite a while, so I will have to check on this later. — Jee Seok Yoon, Mar 12 '14 at 23:41
Perhaps related, perhaps not: at least once, when I experienced IntelliJ running particularly slowly, I noticed it coincided with extremely high I/O. Wiping out its cache fixed the problem. I suspect something in the cache became corrupted, and the IDE wasn't coping well with it. — Mike Strobel, Mar 19 '14 at 14:25
@YannCébron The Intellij IDEA 13 also has a bug with finding files, Link: https://www.dropbox.com/s/j1oa5ofp4dpdaqh/1.jpg — twlkyao, May 11 '14 at 08:28
i had a good result with this configuration : -Xms128m -Xmx1750m -XX:MaxPermSize=850m -XX:ReservedCodeCacheSize=396m — mirzaei, Jun 18 '14 at 10:01
just cleaning up cache and restart worked for me too. File -> Invalidates Caches... in intellij 14 — demian, Sep 30 '15 at 18:07

Jason D · Accepted Answer · 2020-02-26T16:39:30.617

260

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

edited Feb 26 '20 at 16:39

answered Mar 19 '14 at 14:21

Jason D

8,023
10
33
39

22

Thanks Jason.. This seems to have done the trick for me. Increasing heap even just to 2GB (-Xmx2048m) was enough to see significant boost in performance. – Carl Karawani Mar 24 '14 at 17:58
3

I have a total of 8GB RAM and changing to -Xms512m -Xmx850m -XX:MaxPermSize=1024m didn't worked for me. – coding_idiot Jul 24 '14 at 18:39
2

In that case, Have you tried with -Xmx4096 ? You might also want to try values like -Xmx2048 or -Xmx3192 As @CarlKarawani pointed out, even a 2GB heap increase seems to be enough to boost performance. – Jason D Jul 24 '14 at 20:39
For my machine with 8GB of memory, I found this worked: -Xms512m -Xmx1024m -XX:MaxPermSize=1024m – brokethebuildagain Nov 25 '14 at 18:15
1

@CullenJ Thanks for that. I've found that it varies depending on how big my project is. My largest project needs 8 GB, but I've seen it work for less. – Jason D Nov 25 '14 at 20:17
@JasonD Any higher max heap seemed to crash my JVM; that was the highest I could go by trial-and-error. – brokethebuildagain Nov 25 '14 at 20:19
2

Makes sense, seem to be different depending on the machine too. – Jason D Nov 25 '14 at 20:23
1

@JasonD I had an unrelated problem - the exact same program grinding along in IntelliJ but lightening fast in Eclipse - only strange thing I noticed was the IntelliJ console was complaining about spitting out lots of logs - was going to post a question but tried this first and the slowness has gone! Excellent! – davnicwil Jun 10 '15 at 21:57
1

@davnicwil Glad to hear it helped. Interesting problem that you mentioned going from Eclipse to IntelliJ, sounds like its log processing may be a bit slower than expected. – Jason D Jun 11 '15 at 14:45
2

You just saved my computers life, I was just about to throw it off the window : > – sakis kaliakoudas Sep 29 '15 at 23:01
8

`MaxPermSize` is ignored since Java 8. – user2418306 Apr 04 '16 at 11:11
@user2418306 Correct, though many of us, myself included, have legacy code that still requires Java 6. – Jason D Apr 04 '16 at 22:02
@JasonD That doesn't mean you have to use jdk6. – user2418306 Apr 05 '16 at 11:28
Immediately better in Idea 2016.1, Thank you. – mikedave Jun 06 '16 at 13:29
1

Works on Idea 2016.3.3 as well too. Thanks! I finally also fixed issue with window repainting on Ubuntu – Malakai Feb 04 '17 at 09:19
1

Jetbrains doesn't recommend editing files in the app. Use a custom vm options file instead. See https://intellij-support.jetbrains.com/hc/en-us/articles/206544869-Configuring-JVM-options-and-platform-properties – 0cd May 17 '18 at 19:10
This [answer](https://stackoverflow.com/a/13581526/6805866) might help as it's Max Memory Heap is being now set in *special file* (depending if IDEA was installed via JetBrains Toolbox) using IntellIJ IDEA GUI. – NikolaS Dec 29 '20 at 09:37

score 49 · Answer 2 · answered Dec 12 '13 at 14:48

49

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.

answered Dec 12 '13 at 14:48

Nathan

3,082
1
27
42

3

I removed all the plugins I don't use, or am not likely to need anytime soon (eg. support for Mecurical, internationalization, etc). It took the startup time from literally MINUTES, to about 10-15 seconds). The general performance seems to be much snappier now as well. Oddly enough, the memory footprint didn't change much, in my case, staying around 820MB. – sean.boyer Mar 19 '14 at 21:27
4

Disabling the subversion plugin took my cpu down from 100% to less than 2%. If your IntelliJ 13 is slow it is probably a plugin, this should be the accepted answer. – pllee Jun 06 '14 at 15:22

score 25 · Answer 3 · answered Mar 12 '14 at 01:15

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.

I'd recommend you to fire a bug to [JetBrains official bug tracker](http://youtrack.jetbrains.com) and attach a [CPU snapshot](https://intellij-support.jetbrains.com/entries/29983118-Reporting-performance-problems). — LoKi, Jul 08 '14 at 14:46
Turning off git integration and ideavim improved performance significantly for me. Thanks! — Hari Menon, Sep 24 '14 at 01:41
I changed the memory settings and disabled Git integration. Before that the HTML editor was dreadfully slow on a moderately large project, I contemplated throwing the computer out the window but this seemed to fix it instead :) — Richard G, Jan 01 '16 at 08:01
Turned off git and VCS related plugins, and I'm at peace now. — Sanjay Verma, Feb 17 '17 at 07:09
October 2017 checking in here. This still seems to be a major issue. I just turned off Git integration and saw a massive speed boost. — irrational, Oct 31 '17 at 18:21

score 14 · Answer 4 · answered Oct 13 '14 at 10:30

14

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.

answered Oct 13 '14 at 10:30

paul-g

3,797
2
21
36

3

This was a huge help for me on Ubuntu 14.04 – Charney Kaye Oct 23 '14 at 20:12
2

Going back to 1.7 made it 13.1 perform much better on Ubuntu 14.04. Thanks! – pingw33n Nov 04 '14 at 20:56
Newer IntelliJ versions are already bundled with Java 8: https://intellij-support.jetbrains.com/hc/en-us/articles/206544879-Selecting-the-JDK-version-the-IDE-will-run-under and older versions are not compatible. Also check: http://stackoverflow.com/questions/8382641/installing-idea-on-ubuntu-11-10/8384111#8384111 – Christian Vielma Jan 02 '17 at 13:33

tmeans · Answer 5 · 2014-05-21T02:43:04.137

13

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!

edited May 21 '14 at 02:43

answered Dec 31 '13 at 23:39

tmeans

175
1
6

There seems to be a workaround provided here: http://youtrack.jetbrains.com/issue/IDEA-118529#comment=27-656874 Credit: Tavis Elliott – tmeans Jan 15 '14 at 18:20

score 8 · Answer 6 · edited Dec 31 '14 at 09:12

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)

(OSX 10.9) This took my CPU usage down much more than changing the vm options. I wish I could upvote this multiple times. — pllee, Jun 06 '14 at 15:16
I'd recommend you to fire a bug to [JetBrains official bug tracker](http://youtrack.jetbrains.com) and attach a [CPU snapshot](https://intellij-support.jetbrains.com/entries/29983118-Reporting-performance-problems). — LoKi, Jul 08 '14 at 14:48

score 6 · Answer 7 · edited Dec 22 '19 at 21:00

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

score 5 · Answer 8 · answered May 17 '14 at 19:26

5

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

answered May 17 '14 at 19:26

Dennis

593
6
11

score 5 · Answer 9 · answered Jul 21 '14 at 21:38

5

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.

answered Jul 21 '14 at 21:38

DanT

3,960
5
28
33

score 4 · Answer 10 · answered Oct 09 '14 at 13:59

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.

score 3 · Answer 11 · answered Apr 04 '14 at 06:37

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.

I had the same problem on Mac. It's much faster after I changed JVM from 1.6* to 1.7* in IntelliJ's info.plist. — Lei Zhao, Sep 04 '14 at 00:17

score 2 · Answer 12 · answered Nov 06 '14 at 11:56

2

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.

answered Nov 06 '14 at 11:56

ktamlyn

4,519
2
30
41

user3524762 · Answer 13 · 2016-07-13T05:24:46.563

1

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

edited Jul 13 '16 at 05:24

answered Jul 12 '16 at 00:31

user3524762

582
4
15

score 0 · Answer 14 · answered Dec 13 '13 at 00:26

0

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).

answered Dec 13 '13 at 00:26

Software Engineer

15,457
7
74
102

1

No, this isn't it... I'm having exactly the same issues with long pauses-- especially during file saves, switching editor to a different file, and frame activation. It happens on projects of all sizes and the exact same projects were fine with 12.1. – samkass Dec 17 '13 at 18:52
1

It sounds like it may be either garbage collection, interruptions by the operating system, or a bug in Idea. I think that the latter, although quite possible, is unlikely because I'm using the latest version on quite a powerful macbook pro, along with half a dozen other people doing the same thing, and we're not really having these problems -- although we did when we didn't have enough RAM. We had to update our machines to 16GB in order to give the OS enough spare memory to work with. We were using all free memory for Idea, a VM containing Oracle, and a Jboss server. – Software Engineer Dec 18 '13 at 02:58
Perhaps obviously, you should update the idea64.vmoptions if you are using a 64-bit OS, and idea.vmoptions if using a 32-bit OS. – nrobey Jan 13 '14 at 15:31

score 0 · Answer 15 · answered Oct 06 '14 at 17:40

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.

score 0 · Answer 16 · answered Oct 13 '14 at 01:42

0

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.

answered Oct 13 '14 at 01:42

user3769865

39
4

score 0 · Answer 17 · answered May 09 '16 at 07:02

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.

score 0 · Answer 18 · answered Nov 28 '18 at 23:19

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

score 0 · Answer 19 · answered Jun 21 '19 at 23:34

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.

score 0 · Answer 20 · answered Jan 13 '20 at 11:49

0

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

answered Jan 13 '20 at 11:49

Deepak Patankar

3,076
3
16
35

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

20 Answers20

Linked