blocks|key|715664|text|我注意到禁用许多插件确实有助于加快IntelliJ的速度。例如，我没有开发Android应用程序。关闭与Android开发相关的插件，加快加载时间，使程序在我的机器上运行更加顺畅。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|715665|entityMap^0|0^^$0|@$1|2|3|4|5|6|7|D|8|@]|9|@]|A|$]]|$1|B|3|-4|5|6|7|E|8|@]|9|@]|A|$]]]|C|$]]

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.

blocks|key|715678|text|我已经使用了13从早期的测试版，我没有任何问题。也许是你的特定设置。也许你的项目随着时间的推移而增长，而你最初给出的记忆现在还不够吗？尝试给Idea更多的内存来使用：http://www.jetbrains.com/idea/webhelp/increasing-memory-heap.html+(关于如何做到这一点的说明)。|type|unstyled|depth|inlineStyleRanges|entityRanges|offset|length|data|715679|entityMap|0|LINK|mutability|MUTABLE|url|http://www.jetbrains.com/idea/webhelp/increasing-memory-heap.html^0|2B|1T|0|0^^$0|@$1|2|3|4|5|6|7|L|8|@]|9|@$A|M|B|N|1|O]]|C|$]]|$1|D|3|-4|5|6|7|P|8|@]|9|@]|C|$]]]|E|$F|$5|G|H|I|C|$J|K]]]]

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: <a href="http://www.jetbrains.com/idea/webhelp/increasing-memory-heap.html" rel="nofollow">http://www.jetbrains.com/idea/webhelp/increasing-memory-heap.html</a> (instructions on how to do that).

blocks|key|715681|text|我不能回复以上工程师的职位，因为我还没有50名代表.但我也注意到了同样的事情。关于hg4idea，已经报告了一个问题：http://youtrack.jetbrains.com/issue/IDEA-118529。|type|unstyled|depth|inlineStyleRanges|entityRanges|offset|length|data|715682|除了禁用hg4idea插件之外，目前还没有修复程序。但如果这是你的问题，投票给错误！|715683|编辑:+JetBrains已经修复了build+138-815中的错误！|715684|entityMap|0|LINK|mutability|MUTABLE|url|http://youtrack.jetbrains.com/issue/IDEA-118529^0|1N|1B|0|0|0|0^^$0|@$1|2|3|4|5|6|7|P|8|@]|9|@$A|Q|B|R|1|S]]|C|$]]|$1|D|3|E|5|6|7|T|8|@]|9|@]|C|$]]|$1|F|3|G|5|6|7|U|8|@]|9|@]|C|$]]|$1|H|3|-4|5|6|7|V|8|@]|9|@]|C|$]]]|I|$J|$5|K|L|M|C|$N|O]]]]

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: <a href="http://youtrack.jetbrains.com/issue/IDEA-118529">http://youtrack.jetbrains.com/issue/IDEA-118529</a>. 

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!

blocks|key|101468|text|在我的例子中，GIT集成似乎导致编辑器对13的速度慢得令人沮丧。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|101469|当输入，甚至注释，与GIT集成打开后，大约30个字符，用户界面冻结了一秒左右。通常时间不长，但很烦人。|101470|我使用的是GIT+1.7.8.0。运行在Windows+7+64上，有一个固态驱动器和12G内存，以及一个带有8个CPU的英特尔I7。我尝试了各种方法，比如更新idea64.exe.vmoptions以使用更多的内存，比如-Xmx2400m和-XX:MaxPermSize=2400m，-XX:ParallelGCThreads=6，但是它没有解决问题。|101471|git存储库是1.3GG，有65,000个文件。|101472|我在一个新的git存储库中创建了一个新的"grails“项目，没有问题。我在现有的大型git存储库中创建了一个新的grails项目，intellij非常慢。通过打开项目设置对话框并删除git根，我关闭了git集成，问题就消失了。|101473|我尝试通过13个UI禁用所有的GIT后台操作，但这并没有什么区别。我也尝试了GIT内置和本地模式，但没有什么区别。|101474|在我的例子中，解决方法似乎是禁用GIT集成，直到我需要它，然后只是重新添加git根。如果其他人可以验证同样的问题，那么我们可能会将其报告为问题。|101475|entityMap^0|0|0|0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|P|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|Q|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|R|8|@]|9|@]|A|$]]|$1|F|3|G|5|6|7|S|8|@]|9|@]|A|$]]|$1|H|3|I|5|6|7|T|8|@]|9|@]|A|$]]|$1|J|3|K|5|6|7|U|8|@]|9|@]|A|$]]|$1|L|3|M|5|6|7|V|8|@]|9|@]|A|$]]|$1|N|3|-4|5|6|7|W|8|@]|9|@]|A|$]]]|O|$]]

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.

blocks|key|716756|text|在从12升级到IntelliJ+13的时候，我也遇到了同样的问题。对我起作用的是编辑bin文件夹中的idea64.vm选项，并将最大堆设置为8GB(为512+MB)，最大PermGen设置为至少1GB+(为300+MB).Example如下：|type|unstyled|depth|inlineStyleRanges|entityRanges|data|716757|-Xms128m
-Xmx8192m
-XX:MaxPermSize=1024m|code-block|syntax|javascript|716758|重新启动它的速度要快得多。|716759|IntelliJ+2020在Mac+/Applications/IntelliJ+IDEA.app/Contents/bin/idea.vmoptions上返回到2017年|offset|length|style|CODE|716760|在Mac上，此文件位于以下路径：|716761|IntelliJ+14或15在Mac+/Applications/IntelliJ+IDEA+14.app/Contents/bin/idea.vmoptions上|716762|IntelliJ+13在Mac+/Users/yourusername/Library/Preferences/IntelliJIdea13/idea.vmoptions上|716763|IntelliJ的更新程序(自2017年起)似乎回滚了这一更改，因此您可能需要在更新后重新应用它。|716764|在Ubuntu上，此文件位于此路径中，相对于安装目录：|716765|idea-IU-135.475/bin/idea64.vmoptions|716766|对于2016.2人：|716767|+~/.IdeaIC2016.2/idea64.vmoptions|716768|在Windows+10+(这里显示的社区版本)上，这些文件位于：|716769|C:\Program+Files+(x86)\JetBrains\IntelliJ+IDEA+Community+Edition+2016.1.3\bin\idea64.exe.vmoptions|716770|entityMap^0|0|0|0|I|1N|0|0|J|1Q|0|G|1X|0|0|0|0|0|0|0|0|2Q|0^^$0|@$1|2|3|4|5|6|7|1A|8|@]|9|@]|A|$]]|$1|B|3|C|5|D|7|1B|8|@]|9|@]|A|$E|F]]|$1|G|3|H|5|6|7|1C|8|@]|9|@]|A|$]]|$1|I|3|J|5|6|7|1D|8|@$K|1E|L|1F|M|N]]|9|@]|A|$]]|$1|O|3|P|5|6|7|1G|8|@]|9|@]|A|$]]|$1|Q|3|R|5|6|7|1H|8|@$K|1I|L|1J|M|N]]|9|@]|A|$]]|$1|S|3|T|5|6|7|1K|8|@$K|1L|L|1M|M|N]]|9|@]|A|$]]|$1|U|3|V|5|6|7|1N|8|@]|9|@]|A|$]]|$1|W|3|X|5|6|7|1O|8|@]|9|@]|A|$]]|$1|Y|3|Z|5|D|7|1P|8|@]|9|@]|A|$E|F]]|$1|10|3|11|5|6|7|1Q|8|@]|9|@]|A|$]]|$1|12|3|13|5|D|7|1R|8|@]|9|@]|A|$E|F]]|$1|14|3|15|5|6|7|1S|8|@]|9|@]|A|$]]|$1|16|3|17|5|6|7|1T|8|@$K|1U|L|1V|M|N]]|9|@]|A|$]]|$1|18|3|-4|5|6|7|1W|8|@]|9|@]|A|$]]]|19|$]]

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:

<pre><code>-Xms128m
-Xmx8192m
-XX:MaxPermSize=1024m
</code></pre>

Upon restart it was much faster.

For IntelliJ 2020 going back to 2017 on Mac 
<code>/Applications/IntelliJ IDEA.app/Contents/bin/idea.vmoptions</code>

On a Mac, this file is located in this path: 

For IntelliJ 14 or 15 on Mac
<code>/Applications/IntelliJ IDEA 14.app/Contents/bin/idea.vmoptions</code>

For IntelliJ 13 on Mac
<code>/Users/yourusername/Library/Preferences/IntelliJIdea13/idea.vmoptions</code>

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:

<pre><code>idea-IU-135.475/bin/idea64.vmoptions
</code></pre>

and for 2016.2:

<pre><code> ~/.IdeaIC2016.2/idea64.vmoptions
</code></pre>

On Windows 10 (Community edition shown here) these files are located in:

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

blocks|key|715728|text|我已经通过切换到32位模式来解决我的性能问题。它似乎与运行IntelliJ的JRE有关。它附带了一个32位1.7JRE，在启动idea.exe时使用。如果启动idea64.exe，它将使用系统上安装的64位JRE。在我的例子中，这是一个1.6JDK(我用于开发)。这导致IntelliJ几乎不可用。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|715729|在安装了适当的64位1.7JDK之后，64位模式也很好。|715730|请参阅IntelliJ支持网站上的答案。|offset|length|715731|entityMap|0|LINK|mutability|MUTABLE|url|https://intellij-support.jetbrains.com/entries/23455956-Selecting-the-JDK-version-the-IDE-will-run-under^0|0|0|3|A|0|0^^$0|@$1|2|3|4|5|6|7|P|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|Q|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|R|8|@]|9|@$F|S|G|T|1|U]]|A|$]]|$1|H|3|-4|5|6|7|V|8|@]|9|@]|A|$]]]|I|$J|$5|K|L|M|A|$N|O]]]]

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 <a href="https://intellij-support.jetbrains.com/entries/23455956-Selecting-the-JDK-version-the-IDE-will-run-under" rel="nofollow">IntelliJ Support</a> web site.

blocks|key|716811|text|我也有过类似的问题。在这种情况下，是颠覆插件。(+Mavericks，SVNVersion1.7.10)一旦我禁用了这个IntelliJ，它就可以再次使用了。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|716812|这是从j堆栈获得的：|716813|"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)|code-block|syntax|javascript|716814|其他运行：|716815|"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)|716816|entityMap^0|0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|O|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|P|8|@]|9|@]|A|$]]|$1|D|3|E|5|F|7|Q|8|@]|9|@]|A|$G|H]]|$1|I|3|J|5|6|7|R|8|@]|9|@]|A|$]]|$1|K|3|L|5|F|7|S|8|@]|9|@]|A|$G|H]]|$1|M|3|-4|5|6|7|T|8|@]|9|@]|A|$]]]|N|$]]

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:

<pre><code>"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 &lt;76afcdfb8&gt; (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)
</code></pre>

<hr>

other run:

<pre><code>"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.&lt;init&gt;(Unknown Source)
 at org.apache.xerces.parsers.SAXParser.&lt;init&gt;(Unknown Source)
 at org.apache.xerces.jaxp.SAXParserImpl$JAXPSAXParser.&lt;init&gt;(Unknown Source)
 at org.apache.xerces.jaxp.SAXParserImpl.&lt;init&gt;(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)
</code></pre>

blocks|key|101593|text|75s+->+10+s+intellij启动。我所做的就是从使用默认的32位exe切换到使用64位的exe。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|101594|entityMap^0|0^^$0|@$1|2|3|4|5|6|7|D|8|@]|9|@]|A|$]]|$1|B|3|-4|5|6|7|E|8|@]|9|@]|A|$]]]|C|$]]

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

blocks|key|101654|text|对我来说，问题是一个包含超过1000个文件的nodes_modules文件夹。我必须将目录标记为排除。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|101655|还请参阅这列出的可能出现的问题。|offset|length|101656|entityMap|0|LINK|mutability|MUTABLE|url|http://devnet.jetbrains.com/docs/DOC-192^0|0|4|1|0|0^^$0|@$1|2|3|4|5|6|7|N|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|O|8|@]|9|@$D|P|E|Q|1|R]]|A|$]]|$1|F|3|-4|5|6|7|S|8|@]|9|@]|A|$]]]|G|$H|$5|I|J|K|A|$L|M]]]]

For me the problem was a nodes_modules folder with more than thousand files. I had to mark the directory as excluded.

Also see <a href="http://devnet.jetbrains.com/docs/DOC-192" rel="noreferrer">this</a> list of possible problems.

blocks|key|2273729|text|根据我的经验，IntelliJ版本13的速度明显低于12版本。有几种方法可以加快速度，比如增加intelliJ的VM选项。就像。我使用的是一个maven项目，为此，我将运行程序和导入程序选项增加到4GB。它使事情比以前快得多。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|2273730|entityMap^0|0^^$0|@$1|2|3|4|5|6|7|D|8|@]|9|@]|A|$]]|$1|B|3|-4|5|6|7|E|8|@]|9|@]|A|$]]]|C|$]]

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.

blocks|key|716878|text|我在13.1，我已经发现了以下设置为我创造奇迹:+IDE设置->+Editor+->自动修复延迟(ms)，我已设置为1500+(默认为300)。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|716879|在一个大型项目中，编译器和检查将在交互之间不断展开。延迟可能有助于降低堆压力，并且通常会使整个体验更快。我的cpu也很酷，这可能会有所帮助。|716880|entityMap^0|0|0^^$0|@$1|2|3|4|5|6|7|F|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|G|8|@]|9|@]|A|$]]|$1|D|3|-4|5|6|7|H|8|@]|9|@]|A|$]]]|E|$]]

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.

blocks|key|2273794|text|我的特殊情况(Mac)是我编辑了info.plist以使用java1.7*(不管出于什么原因)，它运行起来就像一条绝对的狗。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|2273795|更改为1.6*并安装了java1.6，而且速度很快。|2273796|entityMap^0|0|0^^$0|@$1|2|3|4|5|6|7|F|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|G|8|@]|9|@]|A|$]]|$1|D|3|-4|5|6|7|H|8|@]|9|@]|A|$]]]|E|$]]

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.

blocks|key|2273829|text|在我的例子中，IntelliJ无意中使用JDK/JRE1.8导致了大规模性能下降。这似乎严重影响了呈现性能，并导致一些意外的崩溃和死锁。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|2273830|这将使IDE无法使用(操作时延迟1-2秒)，即使是一个小的~3KLOC项目也是如此。|2273831|只需确保在运行intellij时使用JDK/JRE1.7：|2273832|JAVA_HOME=/usr/lib/jvm/jdk1.7.0_67+intellij|code-block|syntax|javascript|2273833|(或与您的操作系统等效的任何内容)|2273834|您可以检查用于在Help+->关于->+JRE下运行intellij的JRE。|2273835|entityMap^0|0|0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|Q|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|R|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|S|8|@]|9|@]|A|$]]|$1|F|3|G|5|H|7|T|8|@]|9|@]|A|$I|J]]|$1|K|3|L|5|6|7|U|8|@]|9|@]|A|$]]|$1|M|3|N|5|6|7|V|8|@]|9|@]|A|$]]|$1|O|3|-4|5|6|7|W|8|@]|9|@]|A|$]]]|P|$]]

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:

<pre><code>JAVA_HOME=/usr/lib/jvm/jdk1.7.0_67 intellij
</code></pre>

(or whatever the equivalent is for your OS)

You can check the JRE that is being used to run intellij under Help -> About -> JRE.

blocks|key|2273883|text|在我的例子中，我正在Moodle中开发，它创建了巨大的JS和CSS最小化文件。一旦我将这些“缓存”的文件从项目中“缓存”出来，InitelliJ就会再次正常运行。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|2273884|entityMap^0|0^^$0|@$1|2|3|4|5|6|7|D|8|@]|9|@]|A|$]]|$1|B|3|-4|5|6|7|E|8|@]|9|@]|A|$]]]|C|$]]

In my case I am developing within Moodle which creates huge JS and CSS minified files. Once I <code>excluded</code> theses "cached" minified files from the project, InitelliJ ran normally again.

blocks|key|101863|text|我面对的是Intellij+2016.1(64位)和JDK1.8(64位)的缓慢性能。我转到|type|unstyled|depth|inlineStyleRanges|entityRanges|data|101864|64位intellij|unordered-list-item|101865|64位Java+8作为JAVA_HOME路径(这是运行64位Intellij所必需的)|101866|32位Java+8作为JDK用于Intellij项目(File+->+Project+Structure+x+projects+->+)。|101867|通过这种组合，Intellij的性能现在是相当好的。|101868|entityMap^0|0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|M|8|@]|9|@]|A|$]]|$1|B|3|C|5|D|7|N|8|@]|9|@]|A|$]]|$1|E|3|F|5|D|7|O|8|@]|9|@]|A|$]]|$1|G|3|H|5|D|7|P|8|@]|9|@]|A|$]]|$1|I|3|J|5|6|7|Q|8|@]|9|@]|A|$]]|$1|K|3|-4|5|6|7|R|8|@]|9|@]|A|$]]]|L|$]]

I was facing sluggish performance with Intellij 2016.1(64-bit) and JDK 1.8(64-bit). 
I switched to

<ul>
<li>64 bit intellij</li>
<li>64 bit Java 8 as JAVA_HOME path (This is required to run 64-bit Intellij)</li>
<li>32 bit Java 8 as JDK to be used for Intellij projects (File -> Project Structure | Project Settings -> Project | Project SDK).</li>
</ul>

By this combination, now Intellij performance is quite OK.

blocks|key|101898|text|我遇到了类似的问题，启动和堆问题都很慢，增加VM并没有造成太大的影响，只是延迟了不可避免的问题，我的修复方法是通过File+>+InvalidateCaches/Restart使缓存失效。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|101899|https://www.jetbrains.com/help/idea/2016.1/cleaning-system-cache.html|offset|length|101900|entityMap|0|LINK|mutability|MUTABLE|url^0|0|0|1X|0|0^^$0|@$1|2|3|4|5|6|7|M|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|N|8|@]|9|@$D|O|E|P|1|Q]]|A|$]]|$1|F|3|-4|5|6|7|R|8|@]|9|@]|A|$]]]|G|$H|$5|I|J|K|A|$L|C]]]]

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. 

<a href="https://www.jetbrains.com/help/idea/2016.1/cleaning-system-cache.html" rel="nofollow">https://www.jetbrains.com/help/idea/2016.1/cleaning-system-cache.html</a>

blocks|key|101935|text|编辑idea.vmoptions文件只是下一次产品更新之前的临时解决方案。请参阅JetBrains帮助页，以获得通过vm设置-+https://www.jetbrains.com/help/idea/tuning-the-ide.html设置设置这些值的永久解决方案。|type|unstyled|depth|inlineStyleRanges|entityRanges|offset|length|data|101936|entityMap|0|LINK|mutability|MUTABLE|url|https://www.jetbrains.com/help/idea/tuning-the-ide.html^0|1S|1J|0|0^^$0|@$1|2|3|4|5|6|7|L|8|@]|9|@$A|M|B|N|1|O]]|C|$]]|$1|D|3|-4|5|6|7|P|8|@]|9|@]|C|$]]]|E|$F|$5|G|H|I|C|$J|K]]]]

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 - <a href="https://www.jetbrains.com/help/idea/tuning-the-ide.html" rel="nofollow noreferrer">https://www.jetbrains.com/help/idea/tuning-the-ide.html</a>

blocks|key|716998|text|增加编译器的堆大小。默认情况下，这个值是700米，随着插件数量的增加，这个值太小了。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|716999|在第2019.1节，它位于这里：|717000|设置+->+生成、执行、部署+->+编译器+->+生成进程堆大小(兆字节)|offset|length|style|BOLD|717001|在我投入4000英镑之后，它解决了我的大部分性能问题。|717002|entityMap^0|0|0|0|2|6|8|I|3|P|C|0|0^^$0|@$1|2|3|4|5|6|7|N|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|O|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|P|8|@$F|Q|G|R|H|I]|$F|S|G|T|H|I]|$F|U|G|V|H|I]|$F|W|G|X|H|I]]|9|@]|A|$]]|$1|J|3|K|5|6|7|Y|8|@]|9|@]|A|$]]|$1|L|3|-4|5|6|7|Z|8|@]|9|@]|A|$]]]|M|$]]

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.

blocks|key|717004|text|我的特殊情况是:在调试模式下运行代码时，我使用了许多method+breakpoints，这使我的intelliJ变慢了。|type|unstyled|depth|inlineStyleRanges|offset|length|style|CODE|entityRanges|data|717005|entityMap^0|Q|I|0^^$0|@$1|2|3|4|5|6|7|H|8|@$9|I|A|J|B|C]]|D|@]|E|$]]|$1|F|3|-4|5|6|7|K|8|@]|D|@]|E|$]]]|G|$]]

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

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?

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

翻译质量差，导致语言生硬或混乱。

没有提供实际的解决方法或示例。

解答不清晰，无法理解或解决问题。

页面排版不美观，阅读体验差。

文章

问答

视频

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

虽然使用IntelliJ 13最终版本一周，但它似乎真的很慢。首先，整个IDE每隔一段时间就会停止一秒钟左右。与12版本相比，Java编辑器的自动完成非常慢。除了使用Dracula主题之外，我没有从默认设置中更改任何内容。这似乎不是我自己的问题。许多人建议将堆大小设置得高于默认值，或者清除缓存，但我没有对这些建议进行检...

问为什么从版本12升级后IntelliJ 13的想法如此缓慢？
EN

Stack Overflow用户

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问为什么从版本12升级后IntelliJ 13的想法如此缓慢？EN