バージョン12からのアップグレード後にIntelliJ 13 IDEAが非常に遅くなるのはなぜですか？

IntelliJ 13 Ultimateエディションを1週間使用していますが、本当に遅いようです。

まず最初に、IDE全体がときどき1秒ほど停止します。Javaエディターのオートコンプリートは、12バージョンに比べて本当に遅いです。

Draculaテーマを使用する以外は、デフォルト設定から何も変更していません。

これは私自身の問題ではないようです。多くの人がヒープサイズをデフォルトよりも大きく設定すること、またはキャッシュをクリアすることを提案しましたが、私はこれらの提案をチェックまたはテストしていません。新しいバージョンのパフォーマンスを向上させるために、いくつかの設定を変更する必要がありますか？

IntelliJ 13では、12からアップグレードした後、同じ問題が発生しました。binフォルダーのidea64.vmoptionsを編集して、最大ヒープを8 GB（以前は512 MB）に設定し、最大PermGenを少なくとも1GBに設定しました（300MBでした）以下の例：

-Xms128m
-Xmx8192m
-XX:MaxPermSize=1024m

再起動すると、はるかに高速でした。

MacでIntelliJ 2020を2017年に戻す場合 /Applications/IntelliJ IDEA.app/Contents/bin/idea.vmoptions

Macでは、このファイルは次のパスにあります。

Mac上のIntelliJ 14または15の場合 /Applications/IntelliJ IDEA 14.app/Contents/bin/idea.vmoptions

Mac上のIntelliJ 13の場合 /Users/yourusername/Library/Preferences/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 Community Edition 2016.1.3\bin\idea64.exe.vmoptions

多くのプラグインを無効にすると、IntelliJの速度が向上することに気づきました。たとえば、私はAndroidアプリケーションを開発していません。Android開発に関連するプラグインをオフにすると、ロード時間が短縮され、プログラムが私のマシンではるかにスムーズに実行されます。

私の場合、GITの統合が原因で、エディターが13でイライラして遅くなっているようです。

入力中、コメントでさえ、GIT統合がオンになっていると、約30文字後、UIが1秒ほどフリーズします。通常は長くはありませんが、非常に迷惑です。

GIT 1.7.8.0を使用しています。ソリッドステートドライブと12 GBのRAM、および8個のCPUを搭載したIntel I7を搭載したWindows 7 64で動作します。-Xmx2400mや-XX：MaxPermSize = 2400m、-XX：ParallelGCThreads = 6など、idea64.exe.vmoptionsを更新してより多くのメモリを使用するなど、さまざまなことを試しましたが、問題は解決しませんでした。

gitリポジトリは1.3ギグで、65,000ファイルです。

新しいgitリポジトリに新しい「grails」プロジェクトを作成しましたが、問題はありません。既存の大きなgitリポジトリに新しいgrailsプロジェクトを作成しましたが、intellijが遅いです。プロジェクト設定ダイアログを開いてgitルートを削除することでgit統合をオフにしたので、問題は解消されました。

13 UIを使用してすべてのGITバックグラウンド操作を無効にしてみましたが、違いはありませんでした。また、GIT組み込みモードとネイティブモードの両方を試しましたが、違いはありませんでした。

私の場合、回避策は、必要になるまでGIT統合を無効にしてから、Gitルートを再度追加することです。他の誰かが同じ問題を確認できる場合は、問題として報告することがあります。

私の場合、IntelliJが誤ってJDK / JRE 1.8を使用したことが原因で、パフォーマンスが大幅に低下しました。これはレンダリングのパフォーマンスに非常に悪い影響を与えるようで、予期しないクラッシュやデッドロックを引き起こすこともあります。

これにより、小さな〜3KLOCプロジェクトでもIDEが使用できなくなります（操作のレイテンシが1〜2秒）。

intellijを実行するときは、JDK / JRE 1.7を使用していることを確認してください。

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

（または同等のものはあなたのOSのものです）

Help-> About-> JREで、intellijの実行に使用されているJREを確認できます。

さて、上記のエンジニアDolleryの投稿にはまだ返信できません。まだ50人の担当者がいないためです...しかし、同じことに気づきました。：一つの問題は、hg4ideaについてすでに報告されているhttp://youtrack.jetbrains.com/issue/IDEA-118529。

hg4ideaプラグインを無効にする以外はまだ修正はありません。しかし、それがあなたの問題であることが判明した場合は、バグに投票してください！

編集：JetBrainsはビルドIU-138-815のバグを修正しました！

同様の問題がありました。その場合、それは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)

以下のオプション（idea64.exe.vmoptions）での最高のエクスペリエンス：

    -サーバ
    -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

75s-> 10s intellijスタートアップ。私がしたことは、デフォルトの32ビットexeの使用から64ビットexeの使用への切り替えだけでした。

私にとっての問題は、1,000を超えるファイルが含まれるnodes_modulesフォルダーでした。ディレクトリを除外済みとしてマークする必要がありました。

考えられる問題のこのリストも参照してください。

13.1を使用していますが、次の設定がうまく機能することがわかりました。

大規模なプロジェクトでは、コンパイラーとインスペクションが常に相互作用を開始します。遅延により、ヒーププレッシャーが軽減され、全体的なエクスペリエンスが大幅に速くなります。私のCPUもかなり涼しく、おそらく役立つでしょう。

32ビットモードに切り替えることで、パフォーマンスの問題を解決しました。IntelliJを実行するJREに関連しているようです。idea.exeの起動時に使用される32ビットの1.7 JREが同梱されています。idea64.exeを起動すると、システムにインストールされている64ビットJREが使用されます。私の場合、これは1.6 JDK（私が開発に使用するもの）でした。これにより、IntelliJはほとんど使用できなくなりました。

適切な64ビット1.7 JDKをインストールした後、64ビットモードでもすべて問題なく動作しました。

IntelliJサポート Webサイトで回答を参照してください。

私の場合、巨大なJSおよびCSSの縮小ファイルを作成するMoodle内で開発しています。私は一度excludedプロジェクトから縮小さのファイルを「キャッシュされた」論文、InitelliJは再び正常に走りました。

非常に遅い起動とヒープの問題で同様の問題がありましたが、VMを増やしても大きな違いはありませんでしたが、必然的に遅延しました。修正は、ファイル> InvalidateCaches / Restartでキャッシュを無効にすることでした。

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

初期のベータ版から13を使用していますが、まったく問題ありません。多分それはあなたの特定の設定です。多分あなたのプロジェクトは時間の経過とともに成長し、あなたがアイデアを最初に与えたメモリは現在それのために十分ではありませんか？Ideaで使用するメモリを増やしてみてください：http : //www.jetbrains.com/idea/webhelp/increasing-memory-heap.html（その方法の手順）。

IntelliJバージョン13は、私の経験から、12バージョンよりも著しく遅いです。intelliJのVMオプションを増やすなど、速度を上げる方法はいくつかあります。たとえば 私はMavenプロジェクトを使用しており、そのためにランナーとインポーターのオプションを4GBに増やしました。以前よりずっと速くなりました。

私の特定のケース（Mac）は、java.1.7 *を使用するようにinfo.plistを編集しました（何らかの理由で）、それは絶対的な犬のように実行されました。

1.6 *に戻し、Java 1.6をインストールしたところ、高速でした。

Intellij 2016.1（64ビット）とJDK 1.8（64ビット）でパフォーマンスが低下していました。に切り替えました

• 64ビットIntellij
• JAVA_HOMEパスとしての64ビットJava 8（これは64ビットIntellijを実行するために必要です）
• Intellijプロジェクトに使用されるJDKとしての32ビットJava 8（ファイル->プロジェクト構造|プロジェクト設定->プロジェクト|プロジェクトSDK）。

この組み合わせにより、Intellijのパフォーマンスはまったく問題ありません。

idea.vmoptionsファイルの編集は、次の製品アップデートまでの一時的な解決策にすぎません。vm設定-https : //www.jetbrains.com/help/idea/tuning-the-ide.htmlを介してこれらの値を設定するためのより永続的な解決策については、JetBrainsヘルプページを参照してください

コンパイラのヒープサイズを増やします。デフォルトでは、値は700mで、プラグインの数が増えると小さすぎます。

v2019.1では、次の場所にあります。

設定 -> ビルド、実行、配置 -> コンパイラ -> ビルドプロセスヒープサイズ（MB）

そこに4000を置いた後、それは私のパフォーマンス問題のほとんどを解決しました。

私の特定のケース：私がmethod breakpointsコードをデバッグモードで実行している間、私は何回か持っていたため、私のintelliJが遅くなりました。