为什么IntelliJ 13 IDEA从12版本升级后这么慢?

我注意到禁用许多插件确实有助于提高IntelliJ的速度。例如，我不是在开发Android应用程序。关闭与Android开发相关的插件可以加快加载时间，并使程序在我的机器上运行得更流畅。

从早期测试开始，我就一直在使用13，没有任何问题。也许是你的特定设置。也许您的项目随着时间的推移而增长，您最初给Idea的内存现在已经不够用了?尝试给Idea更多的内存来使用:http://www.jetbrains.com/idea/webhelp/increasing-memory-heap.html(如何做到这一点的说明)。

好吧，我不能回复上面工程师Dollery的帖子，因为我还没有50个代表…但我也注意到了同样的事情关于hg4idea: http://youtrack.jetbrains.com/issue/IDEA-118529已经报告了一个问题。

除了禁用hg4idea插件，目前还没有任何修复方法。但如果这是你的问题，那就投票给虫子吧!

编辑:JetBrains已经修复了build IU-138-815中的错误!

在我的例子中，GIT集成似乎导致编辑器在使用13时慢得令人沮丧。

在GIT集成开启的情况下，在输入大约30个字符后，用户界面会冻结一秒钟左右。它通常不长，但很烦人。

我使用的是GIT 1.7.8.0。运行于Windows 7 64，固态硬盘，12g内存，intel I7, 8个cpu。我尝试了各种方法，比如更新idea64.exe。vmoptions使用更多的内存，如-Xmx2400m和-XX:MaxPermSize=2400m， -XX:ParallelGCThreads=6，但这并没有解决问题。

git存储库是1.3 gb，包含65,000个文件。

我在新的git存储库中创建了一个新的“grails”项目，没有问题。我在现有的大型git存储库中创建了一个新的grails项目，intellij很慢。我通过打开项目设置对话框并删除git根来关闭git集成，问题就消失了。

我尝试通过13个UI禁用所有GIT后台操作，但没有什么不同。我还尝试了GIT内置模式和本机模式，没有什么不同。

在我的情况下，解决办法似乎是禁用GIT集成，直到我需要它，然后重新添加GIT根。如果其他人可以验证相同的问题，那么我们可能会将其报告为问题。

-Xms128m
-Xmx8192m
-XX:MaxPermSize=1024m

重新启动后，速度要快得多。

对于IntelliJ 2020回到Mac上的2017年 /Applications/IntelliJ IDEA.app/Contents/bin/idea.vmoptions < / p >

在Mac上，这个文件位于这个路径:

IntelliJ 14或15在Mac上 /Applications/IntelliJ IDEA 14.app/Contents/bin/idea.vmoptions < / p > IntelliJ 13在Mac上

/Users/yourusername/Library/Preferences/IntelliJIdea13/idea.vmoptions < / p >

IntelliJ的更新程序(自2017年以来)似乎会将此更改回滚，因此您可能需要在更新后重新应用它。

在Ubuntu Linux上，这个文件位于相对于安装目录的这个路径:

idea-IU-135.475/bin/idea64.vmoptions

2016.2:

 ~/.IdeaIC2016.2/idea64.vmoptions

在Windows 10(社区版显示在这里)，这些文件位于:

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

我已经通过切换到32位模式解决了性能问题。它似乎与运行IntelliJ的JRE有关。它附带32位1.7 JRE，在启动idea.exe时使用。如果启动idea64.exe，它使用安装在系统上的64位JRE。在我的例子中，使用的是1.6版本的JDK(我用于开发的JDK)。这导致IntelliJ几乎无法使用。

在安装了一个合适的64位1.7 JDK之后，64位模式也没问题。

在IntelliJ支持网站上可以看到答案。

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

其他运行:

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

75s -> 10s intellij启动。我所做的就是从默认的32位exe切换到64位exe。

对我来说，问题是一个包含上千个文件的nodes_modules文件夹。我不得不把这个目录标为排除目录。

也可以查看这可能的问题列表。

根据我的经验，IntelliJ版本13明显比12版本慢。有几种方法可以加快速度，比如增加intelliJ的VM选项。如。我正在使用一个maven项目，为此我将运行器和导入器选项增加到4GB。它让事情变得比以前快多了。

我在13.1上，我发现以下设置对我来说很神奇:IDE设置—>编辑器—>自动重解析延迟(毫秒)，我已设置为1500(默认为300)。

在一个大型项目中，编译器和检查将在交互之间不断启动。延迟可能有助于减少堆压力，并通常使整个体验更快。我的cpu也更酷，这可能有帮助。

我的特殊情况(Mac)是我编辑信息。Plist使用Java 1.7*(不管什么原因)，它运行起来像一条狗。

改回1.6*，安装java 1.6，速度很快。

在我的例子中，大量性能下降是由IntelliJ无意中使用JDK/JRE 1.8引起的。这似乎会严重影响渲染性能，还会导致一些意想不到的崩溃和死锁。

这将导致IDE无法使用(操作延迟1-2s)，即使是一个小的~3KLOC项目。

在运行intellij时，请确保您使用的是JDK/JRE 1.7:

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

(或任何与你的操作系统相同的东西)

您可以在Help -> About -> JRE中查看运行intellij的JRE版本。

在我的情况下，我在Moodle中开发，它会创建巨大的JS和CSS压缩文件。一旦我excluded从项目中“缓存”了最小化的文件，InitelliJ又正常运行了。

以下选项的最佳体验(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

• 64位intellij
• 64位Java 8作为JAVA_HOME路径(这是运行64位Intellij所需的)
• 32位Java 8作为Intellij项目使用的JDK(文件->项目结构|项目设置->项目|项目SDK)。

通过这种组合，现在Intellij的性能是相当不错的。

我有一个非常缓慢的启动和堆问题类似的问题，增加虚拟机并没有产生巨大的差异，只是延迟了不可避免的，对我的修复是通过文件> InvalidateCaches/重启使缓存无效。

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

编辑想法。Vmoptions文件只是下一次产品更新之前的临时解决方案。请参阅JetBrains帮助页面，以获得通过vm settings - https://www.jetbrains.com/help/idea/tuning-the-ide.html设置这些值的更永久的解决方案

增加编译器的堆大小。默认值是700m，随着插件数量的增加，这个值太小了。

在v2019.1中，它位于这里:

__abc0 -> __abc1 -> __abc2 -> __abc3

在我放了4000之后，它解决了我的大部分性能问题。