버전 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에서이 파일은 다음 경로에 있습니다. /Users/yourusername/Library/Preferences/IntelliJIdea13/idea.vmoptions
Mac의 IntelliJ 14 또는 15의 경우 /Applications/IntelliJ IDEA 14.app/Contents/bin/idea.vmoptions
Mac의 IntelliJ 2016, 2017 이상 /Applications/IntelliJ IDEA.app/Contents/bin/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를 업데이트하는 등 다양한 작업을 시도했지만 문제를 해결하지 못했습니다.
git 저장소는 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의 게시물에 답장을 보낼 수는 없지만 같은 것을 발견했습니다. 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 : + UseParNewGC
-XX : 병렬 GCThreads = 4
-XX : + ConcMarkSweepGC 사용
-XX : 결론 = 4
-XX : + CMSClassUnloadingEnabled
-XX : + CMSParallelRemarkEnabled
-XX : CMSInitiatingOcupancyFraction = 65
-XX : + CMSScavengeBefore 비고
-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. All I did was switch from using the default 32bit exe to using the 64bit exe.
For me the problem was a nodes_modules folder with more than thousand files. I had to mark the directory as excluded.
Also see this list of possible problems.
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.
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 IntelliJ Support web site.
In my case I am developing within Moodle which creates huge JS and CSS minified files. Once I excluded theses "cached" minified files from the project, InitelliJ ran normally again.
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.
https://www.jetbrains.com/help/idea/2016.1/cleaning-system-cache.html
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: http://www.jetbrains.com/idea/webhelp/increasing-memory-heap.html (instructions on how to do that).
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.
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.
I was facing sluggish performance with Intellij 2016.1(64-bit) and JDK 1.8(64-bit). I switched to
- 64 bit intellij
- 64 bit Java 8 as JAVA_HOME path (This is required to run 64-bit Intellij)
- 32 bit Java 8 as JDK to be used for Intellij projects (File -> Project Structure | Project Settings -> Project | Project SDK).
By this combination, now Intellij performance is quite OK.
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 - https://www.jetbrains.com/help/idea/tuning-the-ide.html
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.
'Programming' 카테고리의 다른 글
| 로컬 저장소를 추가하고 원격 저장소로 취급하는 방법 (0) | 2020.05.05 |
|---|---|
| C ++ 11 자동 키워드가 너무 많습니까? (0) | 2020.05.05 |
| 파이썬에서 "i + = x"는 "i = i + x"와 언제 다릅니 까? (0) | 2020.05.05 |
| Java에서 가비지 수집을 강제하는 방법은 무엇입니까? (0) | 2020.05.05 |
| XML에서 '이미지에 contentDescription 속성 누락' (0) | 2020.05.05 |