Dlaczego IntelliJ 13 IDEA jest taki wolny po aktualizacji z wersji 12?

Podczas korzystania z najnowszej edycji IntelliJ 13 przez tydzień wydaje się być bardzo powolna.

Po pierwsze, całe IDE zatrzymuje się na sekundę mniej więcej raz na jakiś czas. Automatyczne uzupełnianie edytora Java jest naprawdę wolne w porównaniu do wersji 12.

Nie zmieniłem niczego od ustawień domyślnych innych niż użycie motywu Dracula.

Wydaje się, że to nie jest mój problem. Wiele osób sugerowało ustawienie wielkości sterty na wartość wyższą niż domyślna lub wyczyszczenie pamięci podręcznej, ale nie sprawdziłem ani nie przetestowałem tych sugestii. Czy muszę zmienić niektóre ustawienia, aby poprawić wydajność nowej wersji?

Miałem ten sam problem ze spowolnieniem w IntelliJ 13 po aktualizacji z 12. To, co zadziałało, to edytowanie opcji idea64.vm w folderze bin i ustawianie maksymalnej sterty na 8 GB (było 512 MB), a Max PermGen na co najmniej 1 GB (było 300 MB). Przykład poniżej:

-Xms128m
-Xmx8192m
-XX:MaxPermSize=1024m

Po ponownym uruchomieniu było znacznie szybciej.

Dla IntelliJ 2020 wraca do 2017 roku na Macu /Applications/IntelliJ IDEA.app/Contents/bin/idea.vmoptions

Na komputerze Mac ten plik znajduje się w następującej ścieżce:

Dla IntelliJ 14 lub 15 na Macu /Applications/IntelliJ IDEA 14.app/Contents/bin/idea.vmoptions

Dla IntelliJ 13 na Macu /Users/yourusername/Library/Preferences/IntelliJIdea13/idea.vmoptions

Aktualizator IntelliJ (od 2017 r.) Wydaje się przywracać tę zmianę, więc może być konieczne jej ponowne zastosowanie po aktualizacji.

W systemie Ubuntu Linux ten plik znajduje się w tej ścieżce względem katalogu instalacyjnego:

idea-IU-135.475/bin/idea64.vmoptions

i na 2016 r.2:

 ~/.IdeaIC2016.2/idea64.vmoptions

W systemie Windows 10 (pokazana tutaj edycja Community) pliki te znajdują się w:

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

Zauważyłem, że wyłączenie wielu wtyczek naprawdę pomaga przyspieszyć IntelliJ. Na przykład nie rozwijam aplikacji na Androida. Wyłączenie wtyczek związanych z programowaniem Androida przyspiesza ładowanie i sprawia, że ​​program działa znacznie płynniej na moim komputerze.

W moim przypadku integracja GIT wydaje się powodować frustrujące spowolnienie edytora przy 13.

Podczas pisania, nawet komentarzy, przy włączonej integracji GIT, po około 30 znakach interfejs użytkownika zawiesza się na sekundę. Zwykle nie jest długi, ale bardzo denerwujący.

Używam GIT 1.7.8.0. Działa na systemie Windows 7 64 z dyskiem SSD i 12 koncertami pamięci RAM oraz procesorem Intel I7 z 8 procesorami. Próbowałem różnych rzeczy, takich jak aktualizacja opcji idea64.exe.vm, aby użyć więcej pamięci, takich jak -Xmx2400m i -XX: MaxPermSize = 2400m, -XX: ParallelGCThreads = 6, ale to nie rozwiązało problemu.

Repozytorium git to 1,3 koncertów z 65 000 plików.

Stworzyłem nowy projekt „Grails” w nowym repozytorium git i nie ma problemu. Stworzyłem nowy projekt Grails w istniejącym dużym repozytorium git, a intellij działa powoli. Wyłączyłem integrację git, otwierając okno dialogowe ustawień projektu i usuwając root git, a problem zniknął.

Próbowałem wyłączyć wszystkie operacje w tle GIT za pośrednictwem 13 interfejsu użytkownika, ale to nie miało znaczenia. Wypróbowałem również tryby wbudowane w GIT i tryby natywne, i to nie miało znaczenia.

W moim przypadku obejściem wydaje się być wyłączenie integracji GIT, dopóki jej nie potrzebuję, a następnie ponowne dodanie katalogu głównego git. Jeśli ktokolwiek może zweryfikować ten sam problem, możemy zgłosić go jako problem.

W moim przypadku znaczne obniżenie wydajności spowodowane było przez przypadkowe użycie IntelliJ w JDK / JRE 1.8. Wydaje się, że wpływa to dość źle na wydajność renderowania, a także prowadzi do nieoczekiwanych awarii i zakleszczeń.

Czyni to IDE bezużytecznym (opóźnienie 1-2s na operacjach) nawet dla małego projektu ~ 3KLOC.

Upewnij się tylko, że używasz JDK / JRE 1.7 podczas uruchamiania intellij:

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

(lub jakikolwiek odpowiednik dla twojego systemu operacyjnego)

Możesz sprawdzić środowisko JRE, które jest używane do uruchomienia programu Intellij, klikając Pomoc -> Informacje -> JRE.

Nie mogę odpowiedzieć na powyższy post Engineer Dollery, ponieważ nie mam jeszcze 50 powtórzeń ... ale zauważyłem to samo. Zgłoszono już jeden problem dotyczący hg4idea: http://youtrack.jetbrains.com/issue/IDEA-118529 .

Nie ma jeszcze poprawki oprócz wyłączenia wtyczki hg4idea. Ale jeśli okaże się, że to twój problem, głosuj na błąd!

Edycja: JetBrains naprawił błąd w kompilacji IU-138-815!

Miałem podobny problem. W takim przypadku była to wtyczka Subversion. (Mac Mavericks, SVN wersja 1.7.10) Po wyłączeniu IntelliJ stał się ponownie użyteczny.

Dostałem to z 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)

inny bieg:

"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)

Najlepsze wrażenia z następujących opcji (idea64.exe.vmoptions):

    -serwer
    -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 startup. Wszystko, co zrobiłem, to zmiana domyślnego 32-bitowego exe na użycie 64-bitowego exe.

Dla mnie problemem był folder nodes_modules z ponad tysiącem plików. Musiałem oznaczyć katalog jako wykluczony.

Również zobaczyć tę listę możliwych problemów.

Mam 13.1 i znalazłem następujące ustawienie, które działa dla mnie cuda: Ustawienia IDE -> Edytor -> Opóźnienie autoreparowania (ms), które ustawiłem na 1500 (domyślnie 300).

W dużym projekcie kompilator i kontrole byłyby uruchamiane między interakcjami. Opóźnienie może pomóc zmniejszyć nacisk sterty i ogólnie przyspieszyć całe doświadczenie. Mój procesor jest również o wiele fajniejszy, co prawdopodobnie pomaga.

Rozwiązałem problemy z wydajnością, przechodząc do trybu 32-bitowego. Wydaje się, że jest to związane ze środowiskiem JRE, z którym działa IntelliJ. Jest dostarczany z 32-bitową wersją JRE 1.7, która jest używana podczas uruchamiania idea.exe. Po uruchomieniu idea64.exe używa 64-bitowego środowiska JRE zainstalowanego w systemie. W moim przypadku był to 1.6 JDK (ten, którego używam do programowania). To spowodowało, że IntelliJ był prawie bezużyteczny.

Po zainstalowaniu odpowiedniego 64-bitowego JDK 1.7 wszystko było w porządku również w trybie 64-bitowym.

Zobacz odpowiedź na stronie wsparcia IntelliJ .

W moim przypadku rozwijam się w Moodle, który tworzy ogromne zminimalizowane pliki JS i CSS. Gdy excludedrozprawię „buforowane” zminimalizowane pliki z projektu, InitelliJ znów działa normalnie.

Miałem podobne problemy z bardzo powolnym startem i problemami ze stertą, zwiększenie VM nie zrobiło ogromnej różnicy, po prostu opóźniłem nieuniknione, poprawką było dla mnie unieważnienie pamięci podręcznej poprzez Plik> InvalidateCaches / Restart.

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

Używam 13 od wczesnej wersji beta i nie mam żadnych problemów. Być może są to Twoje określone ustawienia. Może twój projekt urósł z czasem, a pamięć, którą pierwotnie podałeś Idea, nie jest teraz wystarczająca? Spróbuj dać Idea więcej pamięci do pracy: http://www.jetbrains.com/idea/webhelp/increase-memory-heap.html (instrukcje, jak to zrobić).

Z mojego doświadczenia wynika, że ​​IntelliJ wersja 13 jest znacznie wolniejsza niż wersja 12. Istnieje kilka sposobów na przyspieszenie, na przykład zwiększenie opcji VM dla intelliJ. Na przykład Korzystam z projektu maven i do tego zwiększyłem opcje programu do uruchamiania i importowania do 4 GB. Sprawiło, że rzeczy były znacznie szybsze niż wcześniej.

Moją szczególną sprawą (Mac) było edytowanie info.plist w celu użycia java 1.7 * (z jakiegokolwiek powodu) i działało jak absolutny pies.

Zmieniono z powrotem na 1.6 * i zainstalowałem java 1.6, i to było szybkie.

Stawiłem czoła powolnej wydajności z Intellij 2016.1 (64-bit) i JDK 1.8 (64-bit). Przełączyłem się na

• 64-bitowy intellij
• 64-bitowa Java 8 jako ścieżka JAVA_HOME (jest wymagana do uruchomienia 64-bitowej wersji Intellij)
• 32-bitowy Java 8 jako JDK do wykorzystania w projektach Intellijskich (Plik -> Struktura projektu | Ustawienia projektu -> Projekt | SDK projektu).

Dzięki tej kombinacji wydajność Intellij teraz jest całkiem OK.

Edycja pliku idea.vmoptions jest rozwiązaniem tymczasowym do czasu kolejnej aktualizacji produktu. Zobacz strony pomocy JetBrains, aby znaleźć bardziej trwałe rozwiązanie do ustawiania tych wartości za pomocą ustawień VM - https://www.jetbrains.com/help/idea/tuning-the-ide.html

Zwiększ rozmiar sterty dla kompilatora. Domyślnie wartość wynosi 700 m, co jest zbyt małą wartością przy rosnącej liczbie wtyczek.

W wersji 20.1.1 znajduje się tutaj:

Ustawienia -> Kompilacja, wykonanie, wdrożenie -> Kompilator -> Rozmiar sterty procesu kompilacji (MB)

Po wprowadzeniu 4000 rozwiązało to większość moich problemów z wydajnością.

Mój szczególny przypadek: miałem trochę czasu, method breakpointsgdy działałem w trybie debugowania kodu, co spowolniło mój intelliJ.