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?
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:
-Xms128m
-Xmx8192m
-XX:MaxPermSize=1024m
Upon restart it was much faster.
For IntelliJ 2020 going back to 2017 on Mac
/Applications/IntelliJ IDEA.app/Contents/bin/idea.vmoptions
On a Mac, this file is located in this path:
For IntelliJ 14 or 15 on Mac
/Applications/IntelliJ IDEA 14.app/Contents/bin/idea.vmoptions
For IntelliJ 13 on Mac
/Users/yourusername/Library/Preferences/IntelliJIdea13/idea.vmoptions
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:
idea-IU-135.475/bin/idea64.vmoptions
and for 2016.2:
~/.IdeaIC2016.2/idea64.vmoptions
On Windows 10 (Community edition shown here) these files are located in:
C:\Program Files (x86)\JetBrains\IntelliJ IDEA Community Edition 2016.1.3\bin\idea64.exe.vmoptions
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.
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.
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:
JAVA_HOME=/usr/lib/jvm/jdk1.7.0_67 intellij
(or whatever the equivalent is for your OS)
You can check the JRE that is being used to run intellij under Help -> About -> JRE.
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: http://youtrack.jetbrains.com/issue/IDEA-118529.
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!
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:
"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)
other run:
"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)
Best experience with following options (idea64.exe.vmoptions):
-server
-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. 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.
My particular case:
I had a number of method breakpoints while I was running my code in debug mode, which made my intelliJ slow.
Related
I have no idea how to get IntelliJ IDEA 2021.1 working with WSL. I spent two days searching trough internet but I wasn't able to get it running. I am able to create new project with JDK located in WSL but when I press "play button" I receive this:
Executing pre-compile tasks...
Loading Ant configuration...
Running Ant tasks...
Cannot assign requested address: bind
Synchronizing output directories...
4/16/2021 7:57 PM - Build completed with 1 error and 0 warnings in 77 ms
What I tried was also to use maven from WSL but that also didn't help. Does anyone has idea what I am doing wrong?
Jetbrains added an option to work around the issue (has to do with your WLS2 /etc/resolv.conf being modified due to VPNs, etc.):
https://youtrack.jetbrains.com/issue/IDEA-265522#focus=Comments-27-4808360.0-0
From the issue link:
Thanks, the issue with generateResolvConf=false in /etc/wsl.conf is reproduced. The fix will be available in 2021.1.x builds, exact fix version will be available later (see "Available in" field).
After updating to a version with the fix, please do the following to change how Windows host IP is obtained:
Open "Help | Find Action...", locate "Registry..." there and open it.
In the opened "Registry" dialog, find wsl.obtain.windows.host.ip.alternatively registry key (disabled by default) and enable it.
Restart IDE to apply the changes.
I have decided to take on MCP and have downloaded it, however, when running the decompile.bat, it returns an error.
(I'm running 32-bit Windows 10)
Here is what it returned:
'"C:\Program Files\Java\jdk1.8.0_65\bin\java" -jar runtime\bin\fernflower.jar -din=1 -rbr=1 -dgs=1 -asc=1 -rsy=1 -iec=1 -jvn=1 -log=WARN "-e=jars\libraries\net/java/jinput\jinput\2.0.5\jinput-2.0.5.jar" "-e=jars\libraries\org/lwjgl/lwjgl\lwjgl-platform\2.9.4-nightly-20150209\lwjgl-platform-2.9.4-nightly-20150209-natives-windows.jar" "-e=jars\libraries\com/ibm/icu\icu4j-core-mojang\51.2\icu4j-core-mojang-51.2.jar" "-e=jars\libraries\tv/twitch\twitch-external-platform\4.5\twitch-external-platform-4.5-natives-windows-32.jar" "-e=jars\libraries\org/apache/httpcomponents\httpcore\4.3.2\httpcore-4.3.2.jar" "-e=jars\libraries\org/apache/logging/log4j\log4j-api\2.0-beta9\log4j-api-2.0-beta9.jar" "-e=jars\libraries\org/apache/commons\commons-lang3\3.3.2\commons-lang3-3.3.2.jar" "-e=jars\libraries\net/java/jutils\jutils\1.0.0\jutils-1.0.0.jar" "-e=jars\libraries\net/java/dev/jna\jna\3.4.0\jna-3.4.0.jar" "-e=jars\libraries\com/paulscode\libraryjavasound\20101123\libraryjavasound-20101123.jar" "-e=jars\libraries\net/sf/jopt-simple\jopt-simple\4.6\jopt-simple-4.6.jar" "-e=jars\libraries\com/google/guava\guava\17.0\guava-17.0.jar" "-e=jars\libraries\oshi-project\oshi-core\1.1\oshi-core-1.1.jar" "-e=jars\libraries\commons-logging\commons-logging\1.1.3\commons-logging-1.1.3.jar" "-e=jars\libraries\org/apache/commons\commons-compress\1.8.1\commons-compress-1.8.1.jar" "-e=jars\libraries\net/java/dev/jna\platform\3.4.0\platform-3.4.0.jar" "-e=jars\libraries\com/paulscode\codecjorbis\20101023\codecjorbis-20101023.jar" "-e=jars\libraries\com/paulscode\soundsystem\20120107\soundsystem-20120107.jar" "-e=jars\libraries\com/paulscode\librarylwjglopenal\20100824\librarylwjglopenal-20100824.jar" "-e=jars\libraries\org/lwjgl/lwjgl\lwjgl_util\2.9.4-nightly-20150209\lwjgl_util-2.9.4-nightly-20150209.jar" "-e=jars\libraries\commons-codec\commons-codec\1.9\commons-codec-1.9.jar" "-e=jars\libraries\org/apache/httpcomponents\httpclient\4.3.3\httpclient-4.3.3.jar" "-e=jars\libraries\org/lwjgl/lwjgl\lwjgl\2.9.4-nightly-20150209\lwjgl-2.9.4-nightly-20150209.jar" "-e=jars\libraries\commons-io\commons-io\2.4\commons-io-2.4.jar" "-e=jars\libraries\com/mojang\realms\1.7.39\realms-1.7.39.jar" "-e=jars\libraries\com/mojang\authlib\1.5.21\authlib-1.5.21.jar" "-e=jars\libraries\com/google/code/gson\gson\2.2.4\gson-2.2.4.jar" "-e=jars\libraries\tv/twitch\twitch\6.5\twitch-6.5.jar" "-e=jars\libraries\com/paulscode\codecwav\20101023\codecwav-20101023.jar" "-e=jars\libraries\tv/twitch\twitch-platform\6.5\twitch-platform-6.5-natives-windows-32.jar" "-e=jars\libraries\net/java/jinput\jinput-platform\2.0.5\jinput-platform-2.0.5-natives-windows.jar" "-e=jars\libraries\org/apache/logging/log4j\log4j-core\2.0-beta9\log4j-core-2.0-beta9.jar" "-e=jars\libraries\io/netty\netty-all\4.0.23.Final\netty-all-4.0.23.Final.jar" temp/minecraft_ff_in.jar temp\src\minecraft' failed : 1
Decompile failed
This is caused by the decompilation system running out of RAM. I'm not entirely sure why it's happening, but it also was happening to me.
If you're using Minecraft Forge's ForgeGradle, see this. You can either edit the gradle options file ( .gradle/gradle.properties in your user folder) and add org.gradle.jvmargs=-Xmx2G to it, or you can set the options variable to -Xmx2G (in a command prompt, run set GRADLE_OPTS=-Xmx2G and then gradlew setupDecompWorkspace).
However, given that you referenced decompile.bat, you probably are using MCP without Forge. (Which is fine but forge does make mods easier/more compatible; you may want to consider doing this if you're making a more permanent mod rather than just messing about.) In this case, you can edit MCP's configuration to increase the given RAM.
In the MCP folder, open the conf folder and then open mcp.cfg with a text editor of your choice. Then, find this line (near the bottom)
CmdFernflower = %s -jar %s -din=1 -rbr=0 -dgs=1 -asc=1 -log=WARN {indir} {outdir}
and replace it with this:
CmdFernflower = %s -Xmx2G -jar %s -din=1 -rbr=0 -dgs=1 -asc=1 -log=WARN {indir} {outdir}
(You may need to change other lines also adding -Xmx2G before -jar but it doesn't seem to be needed from my experience).
This will run the decompiler with additional RAM.
Alternatively, if you don't want to mess around with the MCP configuration, MCP910 doesn't seem to have this issue. It works with 1.8.0 instead of 1.8.8, but should still do everything you want.
I know, this answer comes very late, but you should install the 64-bit Version of Java. With the 32-Bit Version, it doesn't work...
I don't know if you can install this on your 32-Bit System, but you can try it. On my 86-Bit System (Windows 8) it works!
I am getting "Could not reserve enough space for object heap" error when I am trying to start hybris server.
I have set
wrapper.java.additional.1=-Xmx1G
wrapper.java.additional.2=-XX:MaxPermSize=1024M
My machine is 64 bit 8GB RAM Windows
I faced the same problem once, The problem in my case was that too many other Applications were running on my system.
So go to the task manager and check the memory available use.
Close some applications and try running.
Also if you are using eclipse Then, In your eclipse.ini file (this is beside the eclipse executable), replace -Xmx256m with -Xmx1024m (or Xmx512m).
This is not compulsory but in certain cases it works.
If you are using some extension then,
Open YOURPATH/config/local.properties file.
Add the following entry:
config/local.properties
build.parallel=true
Save the file.
(In cases where we have multiple cores in the machine, we can tell hybris to utilize these by building in parallel and in certain cases this too works)
I too faced the same probelm. I followed below steps and set the max heap size to 1GB.
Add the following content to local.properties
tomcat.generaloptions=-Xmx4G -ea -Dcom.sun.management.jmxremote -Dcom.sun.management.jmxremote.authenticate=false -Dcom.sun.management.jmxremote.ssl=false -Dorg.tanukisoftware.wrapper.WrapperManager.mbean=true -Djava.endorsed.dirs="%CATALINA_HOME%/lib/endorsed" -Dcatalina.base=%CATALINA_BASE% -Dcatalina.home=%CATALINA_HOME% -Dfile.encoding=UTF-8 -Dlog4j.configuration=log4j_init_tomcat.properties -Djava.util.logging.config.file=jdk_logging.properties -Djava.io.tmpdir="${HYBRIS_TEMP_DIR}"
ant clean all
start hybrisserver
Reference
https://launchpad.support.sap.com/#/notes/0002437669
I've googled and tried all SO answers, but none seems to be working for me.
The CPU usage remains low when inactive, as soon as I start typing, it jumps and takes a few seconds to see what I'm typing. Should be some kind of inspection/intellisense, but disabling it makes IDE useless (IDE means intellisense to me), although I'm willing to give it a try and have already tried the below things, but nothing seems to be working for me.
I've tried the following things :
1. -Xms512m
-Xmx1024m
-XX:MaxPermSize=1024m
-XX:ReservedCodeCacheSize=256m
-ea
-Dsun.io.useCanonCaches=false
-Djava.net.preferIPv4Stack=true
-Djsse.enableSNIExtension=false
-XX:+UseCodeCacheFlushing
-XX:+UseConcMarkSweepGC
-XX:SoftRefLRUPolicyMSPerMB=50
2. Disabled Git & Subversion plugin
3. Disabled "Probable Bugs" in settings -> Inspection
4. Made sure that I'm running Idea64.exe and changing idea64.exe.vmoptions
5. Created a system variable IDEA_JDK_64 to point to JDK7Update60
6. Disabled "AutoPopupCodeCompletion" in Editor->CodeCompletion and changed "CaseSensitiveCompletion" to None.
7. Added {userdir}/.intellij and {project}/.idea to Anti-Virus scan exclusion
This is an old question but I just had similar issue and googling pops this page so it might help someone else in the future.
I am running IntelliJ IDEA 16.1 and writing javascipt was unbearably slow. At the end I tried File | Invalidate Caches/Restart which solved the issue.
Had a discussion with Intellij Support Team
The issue was with only large files (8k+ lines of .js code). Probably, because of system hardware limits.
When I worked with files having less lines of code, it behaved fine.
I am currently trying to build my project using hudson to call maven. I keep getting the problem of out of memoery error. I set the xmx and xms in all environmental variable, hudson configuration and hudson project config. I set the xmx to 1500 mb which should be more than enough as the whole project is less than 1000mb. the machine used to build the project is a server where the maven repo for the team is stored.
Anyone have come acrossed the same problem? Any idea of how it happen?
If you get an OOM during the tests, then you must tell the surefire plugin to fork a new VM for the tests:
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-surefire-plugin</artifactId>
<version>2.5</version>
<configuration>
<forkMode>once</forkMode>
<argLine>-Xms512m -Xmx512m</argLine>
</configuration>
</plugin>
Thank you everyone for answering my question. I have solved the problem by making a heap dump and analysing it. I make a heap dump by passing the following VM args:
-XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=E:/.
I then use Eclipse Memory Analyser to open the java_pidxxxxx.hprof file.
I found out that the listener we used to catch the exception cannot catch the exception. So the exception sort of stays in the VM and hence, memory leak!
Thanks again for all the answers
Do make sure you have enough MaxPermSpace. I've run into problems where the memory allocated to the JVM was sufficient, but the OutOfMemoryError was due to the PermSpace being exhausted. That is not too uncommon when we are dealing with compiling code--particularly if it is compiling code, throwing it away and compiling again. For more information about tuning the garbage collector (and memory) check out these references:
Tuning Garbage Collectionwith the 5.0 Java TM Virtual Machine
Memory Management in the Java HotSpot™ Virtual Machine
In the Memory Management Whitepaper on pages 16-17, it outlines possible reasons for OutOfMemoryErrors. Another defense is to fork the maven process and/or the compiler.
Assuming you are using Sun's JDK, then in Hudson / Manage Hudson / Maven Project Configuration / Global MAVEN_OPTS set the following: -Xmx512m -XX:MaxPermSize=256m
Hudson kicks off a separate task to run Maven jobs. You will need to configure the increased memory in the MAVEN_OPTS text field. The field is located in individual job configuration windows.
Edit: Following up with your comments. Are you by chance forking your compile, running it in a separate execution or forking your junit testing.
Try in your compiler configuration (assuming you have one):
<maxmem>512m</maxmem>
i got the same problem. when trying to instrument the code, hudson (or JVM) throw java out of memory. The solution is: in the configuration of plugin cobertura-maven-plugin, use <maxmem>512m</maxmem>.