버전 12에서 업그레이드 한 후 IntelliJ 13 IDEA가 왜 그렇게 느립니까?

일주일 동안 IntelliJ 13 Ultimate Edition을 사용하는 동안 속도가 느려집니다.

우선, 전체 IDE가 잠시 동안 1 초마다 중지됩니다. Java 편집기의 자동 완성은 12 버전에 비해 실제로 느립니다.

드라큘라 테마를 사용하는 것 이외의 기본 설정에서 아무것도 변경하지 않았습니다.

이것은 내 자신의 문제가 아닌 것 같습니다. 많은 사람들이 힙 크기를 기본값보다 높게 설정하거나 캐시를 지우라고 제안했지만 이러한 제안을 확인하거나 테스트하지 않았습니다. 새 버전의 성능을 향상 시키려면 일부 설정을 변경해야합니까?

12에서 업그레이드 한 후 IntelliJ 13의 속도 저하와 같은 문제가 발생했습니다. bin 폴더에서 idea64.vmoptions를 편집하고 최대 힙을 8GB (512MB)로 설정하고 최대 PermGen을 1GB 이상으로 설정하는 것이 저에게 효과적이었습니다. (현재 300MB) 아래 예 :

-Xms128m
-Xmx8192m
-XX:MaxPermSize=1024m

다시 시작하면 훨씬 빨랐습니다.

Mac에서 2017로 돌아가는 IntelliJ 2020의 경우 /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 애플리케이션을 개발하지 않습니다. 안드로이드 개발과 관련된 플러그인을 끄면 로딩 시간이 단축되고 내 컴퓨터에서 프로그램이 훨씬 부드럽게 실행됩니다.

필자의 경우 GIT 통합으로 인해 편집기가 13로 인해 느려집니다.

GIT 통합을 설정 한 상태에서 입력하거나 주석을 추가하는 동안 약 30 자 후에 UI가 1 초 정도 정지됩니다. 일반적으로 길지는 않지만 매우 성가시다.

GIT 1.7.8.0을 사용하고 있습니다. 솔리드 스테이트 드라이브와 12 기가의 램과 8 개의 CPU가있는 인텔 I7이있는 Windows 7 64에서 실행됩니다. -Xmx2400m 및 -XX : MaxPermSize = 2400m, -XX : ParallelGCThreads = 6과 같이 더 많은 메모리를 사용하도록 idea64.exe.vmoptions를 업데이트하는 등 다양한 작업을 시도했지만 문제를 해결하지 못했습니다.

자식 저장소는 65,000 파일로 1.3 기가입니다.

새 자식 저장소에 새 "grails"프로젝트를 만들었는데 아무런 문제가 없습니다. 기존의 큰 자식 저장소에 새 grails 프로젝트를 만들었고 intellij가 느립니다. 프로젝트 설정 대화 상자를 열고 자식 루트를 삭제하여 자식 통합을 해제하면 문제가 해결됩니다.

13 UI를 통해 모든 GIT 백그라운드 작업을 비활성화하려고 시도했지만 차이가 없었습니다. 또한 GIT 내장 모드와 기본 모드를 모두 시도했지만 아무런 차이가 없었습니다.

필자의 경우 해결 방법은 필요할 때까지 GIT 통합을 비활성화 한 다음 git root를 다시 추가하는 것 같습니다. 다른 사람이 동일한 문제를 확인할 수 있으면 문제로보고 할 수 있습니다.

필자의 경우 JDK / JRE 1.8을 실수로 사용하는 IntelliJ로 인해 엄청난 성능 저하 가 발생했습니다. 이는 렌더링 성능에 상당히 영향을 미치는 것으로 보이며 예기치 않은 충돌 및 교착 상태로 이어집니다.

이렇게하면 작은 ~ 3KLOC 프로젝트에서도 IDE를 사용할 수 없게됩니다 (작업에서 1-2 초의 대기 시간).

intellij를 실행할 때 JDK / JRE 1.7을 사용하고 있는지 확인하십시오.

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

(또는 OS와 동등한 것이 무엇이든)

도움말-> 정보-> JRE에서 intellij를 실행하는 데 사용되는 JRE를 확인할 수 있습니다.

글쎄, 아직 50 명의 담당자가 없기 때문에 위의 Engineer Dollery의 게시물에 답장을 보낼 수는 없지만 같은 것을 눈치 ve습니다. 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 : 예약 코드 캐시 크기 = 240m
    -XX : + UseCompressedOops
    -XX : SoftRefLRUPolicyMSPerMB = 50

    -XX : 병렬 GCThreads = 4
    -XX : + ConcMarkSweepGC 사용
    -XX : 결론 = 4

    -XX : + CMSClassUnloadingEnabled
    -XX : + CMSParallelRemarkEnabled
    -XX : CMSInitiatingOcupancyFraction = 65
    -XX : + CMSScavengeBefore 비고
    -XX : + UseCMSInitiatingOccupancyOnly

    -XX : MaxTenuringThreshold = 1
    -XX : 생존자 비율 = 8
    -XX : + UseCodeCacheFlushing 사용
    -XX : + 공격적 옵션
    -XX : -TraceClassUnloading
    -XX : + 항상 PreTouch
    -XX : + 계층 컴파일

    -Djava.net.preferIPv4Stack = true
    -Dsun.io.useCanonCaches = false
    -Djsse.enableSNIExtension = true
    -ea

75s-> 10s intellij 시작. 내가 한 것은 기본 32 비트 exe 사용에서 64 비트 exe 사용으로 전환하는 것입니다.

나에게 문제는 천 개가 넘는 파일이있는 nodes_modules 폴더였습니다. 디렉토리를 제외 된 것으로 표시해야했습니다.

이 가능한 문제 목록 도 참조하십시오 .

나는 13.1에 있고 나는 다음 설정이 나를 위해 경이로운 것을 발견했다 : IDE 설정-> 편집기-> Autoreparse delay (ms), 1500으로 설정했습니다 (기본값은 300).

대규모 프로젝트에서 컴파일러와 검사는 상호 작용간에 지속적으로 시작됩니다. 지연은 아마도 힙 압력을 줄이는 데 도움이되고 일반적으로 전체 경험을 훨씬 빠르게 만듭니다. 내 CPU도 훨씬 시원합니다. 아마 도움이 될 것입니다.

32 비트 모드로 전환하여 성능 문제를 해결했습니다. IntelliJ가 실행되는 JRE와 관련이있는 것 같습니다. idea.exe를 시작할 때 사용되는 32 비트 1.7 JRE와 함께 제공됩니다. idea64.exe를 시작하면 시스템에 설치된 64 비트 JRE를 사용합니다. 필자의 경우 이것은 1.6 JDK (개발에 사용하는 것)였습니다. 이로 인해 IntelliJ를 거의 사용할 수 없게되었습니다.

적절한 64 비트 1.7 JDK를 설치 한 후 64 비트 모드에서도 모든 것이 정상입니다.

IntelliJ 지원 웹 사이트 에서 답변을 참조하십시오 .

내 경우에는 거대한 JS 및 CSS 축소 파일을 만드는 Moodle 내에서 개발 중입니다. 나는 일단 excluded프로젝트에서 축소 된 파일을 "캐시"논문, InitelliJ 다시 정상적으로 실행.

매우 느린 시작 및 힙 문제와 비슷한 문제가 있었으며 VM을 늘리면 큰 차이가 없었으며 피할 수 없었습니다. 파일> InvalidateCaches / Restart를 통해 캐시를 무효화하는 것이 수정되었습니다.

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

초기 베타 이후로 13을 사용하고 있으며 전혀 문제가 없습니다. 아마도 여러분의 특정 설정일 것입니다. 어쩌면 프로젝트가 시간이 지남에 따라 커졌고 아이디어를 제공 한 메모리만으로는 충분하지 않습니까? http://www.jetbrains.com/idea/webhelp/increasing-memory-heap.html ( 작업 방법에 대한 지침) 과 함께 사용할 수있는 메모리를 Idea에 제공 하십시오 .

IntelliJ 버전 13은 내 경험상 12 버전보다 현저히 느립니다. intelliJ의 VM 옵션을 늘리는 것과 같이 속도를 높이는 몇 가지 방법이 있습니다. 예를 들어. 필자는 maven 프로젝트를 사용하고 있으므로 러너 및 가져 오기 옵션을 4GB로 늘 렸습니다. 이전보다 훨씬 빨라졌습니다.

내 특별한 경우 (Mac)는 info.plist를 편집하여 java 1.7 * (어떤 이유로 든)를 사용했으며 절대 개처럼 실행되었습니다.

1.6 *으로 다시 변경하고 java 1.6을 설치했는데 빠릅니다.

Intellij 2016.1 (64 비트) 및 JDK 1.8 (64 비트)에서 성능이 느려졌습니다. 나는 ~로 바꿨다

• 64 비트 인텔리
• 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가 느려졌습니다.