在使用IntelliJ 13终极版一周的时间里,它似乎真的很慢。
首先,整个IDE每隔一段时间就会停止一秒钟左右。与12版相比,Java编辑器的自动完成非常慢。
除了使用德古拉主题外,我没有对默认设置进行任何更改。
看来这不是我自己的问题。许多人建议将堆大小设置为高于默认值,或清除缓存,但我没有检查或测试这些建议。我是否需要更改某些设置来提高新版本的性能?
在使用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)
根据我的经验,IntelliJ版本13明显比12版本慢。有几种方法可以加快速度,比如增加intelliJ的VM选项。如。我正在使用一个maven项目,为此我将运行器和导入器选项增加到4GB。它让事情变得比以前快多了。
我在13.1上,我发现以下设置对我来说很神奇:IDE设置—>编辑器—>自动重解析延迟(毫秒),我已设置为1500(默认为300)。
在一个大型项目中,编译器和检查将在交互之间不断启动。延迟可能有助于减少堆压力,并通常使整个体验更快。我的cpu也更酷,这可能有帮助。
在我的例子中,由于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版本。
以下选项的最佳体验(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之后,它解决了我的大部分性能问题。