在使用IntelliJ 13终极版一周的时间里,它似乎真的很慢。

首先,整个IDE每隔一段时间就会停止一秒钟左右。与12版相比,Java编辑器的自动完成非常慢。

除了使用德古拉主题外,我没有对默认设置进行任何更改。

看来这不是我自己的问题。许多人建议将堆大小设置为高于默认值,或清除缓存,但我没有检查或测试这些建议。我是否需要更改某些设置来提高新版本的性能?


我注意到禁用许多插件确实有助于提高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根。如果其他人可以验证相同的问题,那么我们可能会将其报告为问题。


从12升级后,我在IntelliJ 13中也遇到了同样的缓慢问题。 对我有效的是编辑想法。在bin文件夹中设置vmoptions,并将最大堆设置为8gb(为512mb),最大PermGen设置为至少1GB(为300MB)。在下面的例子:

-Xms128m
-Xmx8192m
-XX:MaxPermSize=1024m

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

对于IntelliJ 2020,回溯到Mac上的2017年 /应用程序/ IntelliJ IDEA.app /内容/ bin / idea.vmoptions

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

适用于Mac上的IntelliJ 14或15 /Applications/IntelliJ IDEA 14.app/Contents/bin/ IDEA .vmoptions

适用于Mac上的IntelliJ 13 /用户/ yourusername /图书馆/ / IntelliJIdea13 / idea.vmoptions偏好

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社区版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 Support网站上可以看到答案。


我也遇到过类似的问题。 在这种情况下,它就是Subversion插件。(Mac Mavericks, 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文件夹。我不得不把这个目录标为排除目录。

还请参阅可能的问题列表。


根据我的经验,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压缩文件。一旦我从项目中排除了这些“缓存”的最小化文件,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

使用Intellij 2016.1(64位)和JDK 1.8(64位)时,我面临着缓慢的性能。 我换到

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帮助页面,以获得通过虚拟机设置(https://www.jetbrains.com/help/idea/tuning-the-ide.html)设置这些值的更永久的解决方案


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

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

设置->构建,执行,部署->编译器->构建进程堆大小(Mbytes)

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


我的具体情况是: 当我在调试模式下运行代码时,我有许多方法断点,这使得我的intelliJ很慢。