为什么IntelliJ 13 IDEA从版本12升级后如此慢？
在使用IntelliJ 13最终版本一个星期，它似乎真的很慢。
首先，整个IDE每隔一会停一会儿。 与12版本相比，Java编辑器的自动完成速度非常慢。
除了使用德古拉主题之外，我没有改变任何默认设置。
看来这不是我自己的问题。 许多人build议将堆大小设置为高于默认值，或清除caching，但我没有检查或testing这些build议。 我是否需要改变一些设置来改善新版本的性能？
从12升级后，我在IntelliJ 13中遇到了同样的问题。对我而言，编辑bin文件夹中的idea64.vmoptions并将最大堆设置为8 GB（512 MB），将Max PermGen设置为至less1 GB （是300MB）。示例如下：
-Xms128m -Xmx8192m -XX:MaxPermSize=1024m
重启后速度要快得多。
在Mac上，该文件位于以下path中： /Users/yourusername/Library/Preferences/IntelliJIdea13/idea.vmoptions
对于Mac /Applications/IntelliJ IDEA 14.app/Contents/bin/idea.vmoptions上的IntelliJ 14或15 /Applications/IntelliJ IDEA 14.app/Contents/bin/idea.vmoptions
对于/Applications/IntelliJ IDEA.app/Contents/bin/idea.vmoptions或更高的Mac /Applications/IntelliJ IDEA.app/Contents/bin/idea.vmoptions
IntelliJ的2017年更新似乎推出了这个变化，所以你可能需要重新更新后应用它。
在Ubuntu Linux上，该文件位于相对于安装目录的此path中：
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
我注意到，禁用许多插件确实有助于加速IntelliJ。 例如，我没有开发Android应用程序。 打开与Android开发相关的插件，加快了加载速度，并使程序在我的机器上运行得更顺畅。
就我而言，GIT的整合似乎正在让编辑在13岁时变得非常缓慢。
在GIT集成打开的情况下，打字甚至是评论，大约30个字符之后，UI冻结了一秒钟左右。 它通常不长，但非常烦人。
我正在使用GIT 1.7.8.0。 在Windows 7 64上运行固态硬盘，12个RAM和一个带有8个CPU的intel I7。 我尝试了各种各样的东西，比如更新idea64.exe.vmoptions来使用更多的内存，比如-Xmx2400m和-XX：MaxPermSize = 2400m，-XX：ParallelGCThreads = 6，但是没有解决问题。
该git存储库是1.3演出与65,000文件。
我在一个新的git仓库中创build了一个新的“grails”项目，没有问题。 我在现有的大型git仓库中创build了一个新的grails项目，而intellij很慢。 我通过打开项目设置对话框和删除git根closuresgit集成，问题消失。
我尝试通过13 UI禁用所有的GIT后台操作，但没有什么区别。 我也尝试了GIT内置和本机模式，并没有什么区别。
在我的情况下，解决方法似乎是禁用GIT集成，直到我需要它，然后只是重新添加git根。 如果其他人能够validation相同的问题，那么我们可能会将其报告为一个问题。
在我的情况下，由于IntelliJ无意中使用JDK / JRE 1.8而导致性能大幅下降 。 这似乎影响渲染性能相当糟糕，也导致一些意想不到的崩溃和死锁。
这会导致IDE即使是一个小的〜3KLOC项目也不可用（操作时间为1-2s）。
运行intellij时，请确保您使用的是JDK / JRE 1.7：
JAVA_HOME=/usr/lib/jvm/jdk1.7.0_67 intellij
（或任何相当于您的操作系统）
您可以在帮助 – >关于 – > JRE下检查用于运行intellij的JRE。
那么我不能回复上面的工程师Dollery的post，因为我没有50个代表呢，但是我注意到了同样的事情。 关于hg4idea已经报道了一个问题：http：//youtrack.jetbrains.com/issue/IDEA-118529。
除了禁用hg4idea插件，还没有修复。 但如果这是你的问题，投票的错误！
编辑：JetBrains修复了构buildIU-138-815的错误！
我有一个类似的问题。 在这种情况下，它是Subversion插件。 （Mac小牛，SVN版本1.7.10）一旦我禁用了这个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文件夹超过一千个文件。 我必须将目录标记为排除。
也看到这个可能出现的问题列表。
我在13.1，我发现以下设置工程奇迹为我：IDE设置 – >编辑器 – > Autoreparse延迟（毫秒），我已经设置为1500（默认是300）。
在一个大型项目中，编译器和检查将在不同的交互之间不断开始。 延迟也许有助于减less堆压力，并且通常使整个体验更快。 我的CPU也很酷，这可能有帮助。
有以下选项的最佳体验（idea64.exe.vmoptions）：
-服务器
-Xms1g
-Xmx3g
-Xss16m
-XX：NewRatio = 3
-XX：ReservedCodeCacheSize =240米
-XX：+ UseCompressedOops
-XX：SoftRefLRUPolicyMSPerMB = 50
-XX：+ UseParNewGC
-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 =真
-Dsun.io.useCanonCaches = FALSE
-Djsse.enableSNIExtension =真
-ea
我通过切换到32位模式解决了我的性能问题。 这似乎与IntelliJ运行的JRE有关。 它附带一个32位1.7 JRE，用于启动idea.exe。 如果启动idea64.exe，则会使用系统上安装的64位JRE。 在我的情况下，这是一个1.6 JDK（我用于开发）。 这导致IntelliJ几乎无法使用。
在安装一个合适的64位1.7 JDK之后，64位模式下的一切都很好。
请参阅IntelliJ支持网站上的答案。
在我的情况下，我正在开发内Moodle创build巨大的JS和CSS缩小文件。 一旦我从项目中excluded这些“caching”的缩小文件，InitelliJ就再次正常运行。
我遇到类似的问题，开始和堆的问题非常缓慢，增加虚拟机并没有产生太大的影响，只是延迟了不可避免的，我修复的方法是通过文件>无效caching/重新启动来使caching无效。
https://www.jetbrains.com/help/idea/2016.1/cleaning-system-cache.html
自从早期testing版本以来，我一直在使用13，我根本没有任何问题。 也许这是你的具体设置。 也许你的项目已经随着时间的推移而增长了，你原来给Idea的记忆力现在还不够呢？ 尝试给予想法更多的内存来处理： http : //www.jetbrains.com/idea/webhelp/increasing-memory-heap.html （如何做到这一点的说明）。
根据我的经验，IntelliJ版本13显着慢于12版本。 有几种方法可以加快速度，例如增加用于intelliJ的VM选项。 例如。 我正在使用一个maven项目，为此，我将runner和import选项增加到了4GB。 它使事情比以前快得多。
我个人的情况（Mac）是我编辑的info.plist使用Java 1.7 *（无论出于何种原因），它像一个绝对的狗跑。
改回1.6 *并安装了java 1.6，速度很快。
我在Intellij 2016.1（64位）和JDK 1.8（64位）上面临着低迷的performance。 我切换到
- 64位intellij
- 64位Java 8作为JAVA_HOMEpath（这是运行64位Intellij所必需的）
- 32位Java 8作为用于Intellij项目（文件 – >项目结构|项目设置 – >项目|项目SDK）的JDK。
通过这种组合，现在Intellij的performance还是不错的。
