I found that IntelliJ Idea sometimes is becaming irritatingly slow.
Sometimes it is not VERY slow, but sometimes it is slow like bad web page. The impression that is think and waits on each keystroke or each word.
Much slower than Visual Studio.
The speed was one of the main reason I switched from Eclipse. I would not like if IntelliJ will turn to the same as Eclipse but for money.
Are there any means to speed up an IntelliJ?
I have added
editor.zero.latency.typing=true
into idea.properties but had no effect.
UPDATE
Already set
but this didn't help.
UPDATE 2
I found that slowness depends on what is written in code. I.e. it is somehow related with automatic code inspection or something.
I don't want to disable inspection completely, but just don't want it runs each keystroke. Is it possible to increase delays somewhere?
Please report your problems in Jetbrans's youtrack. Usually you need to provide your CPU Usage profile. How to enable it you can read here: Reporting performance problems
If you have a 64-bit machine, you can launch IntelliJ IDEA from idea64.exe, not idea.exe
Second thing, as the comment suggests, you can edit your idea64.exe.vmoptions (that's spelled correct, .vmoptions is the file extension, while .exe is part of the filename) in pathToIntelliJ/bin by increasing values in lines starting from -Xms and -Xmx (that is: memory for JVM while starting and maximum amount of memory). You may not be able to edit this file in place, but you can copy this file to another location (where you have permission to edit it), edit this file and copy it back to /bin folder.
Related
I'm using premake5 here.
It generates my solution/project files, when this happens, VS2015 asks me if I want to reload the modified projects.
If I hit yes, this proceeds to lock up the IDE for a very long time.
Anywhere from 30 seconds to 1 minute I'd say.
Does anyone know of a way to work around this? This is super irritating.
It happens even for the most trivial of changes(modify one project, which only has 1 file in it).
I realize this is a VS problem, and not directly the fault of premake/cmake(or whatever build system you are using), but it totally sucks.
As you said, it's VS related :) But I think you have some problems with your installation : for small projects, reloading the whole solutions should be pretty fast : my personal projects take less than a second to reload (2 to 4 projects per solution, ~100 files per project)
Anyway in the usual course of development, re-generating your projects should not happen that often, except at the very beginning when you need to configure everything.
When you need to add a few files, just add them through Visual Studio : you won't have to run Premake again, and next time you run it, the files will be included by your script anyway. You can do the same with small configuration changes : update your project directly in VS, check that it works, and when it does, upadte the Premake script. You won't have to run Premake then.
I'm using project.vim with VIm to manage large code bases with deep directory structures.
When I switch to another one or create (\C) a new one and do a refresh (\R) project.vim starts displaying messages through the whole process for different directories:
<dir_name> is not a valid directory. [O]K:
I have to press Enter all the time, although the directories exist. I took a look at the code and it checks if the path is a directory. They are.
Maybe there is a fix for this. The directories are under Perforce management, so everything is read-only.
I have to stay at the keyboard and keep pressing Enter for it to go to next directories... For large code bases this is takes a long time.
I contacted the author some time ago, but there was no response.
Did anyone encounter this before?
Could it be the it is bothered by the read-only-ness?
Is there a fix for this?
Thanks
The plugin uses glob() for some of those directory checks, which is affected by the 'wildignore' setting. Try
:set wildignore=
If that fixes the problem (and you have at least Vim version 7.2.51), you can modify the plugin's code to use glob(..., 1) instead.
I have a really strange problem with my Visual Studio.
I usually press CTRL + S pretty often (call me paranoid, well however I got that habit some years ago now and I really don't want to get rid of it :-))
Now I had the issue that I was editing one file, changing a few dozen of strings according to a spec I had open in Word; so I switch around these two tasks pretty often, make one or two changes and then save.
The odd thing is, every once in a while, after saving, my file is suddenly in read-only-mode, so I cannot navigate through my changes (CTRL+Z/CTRL+Y) and have to reopen that file to continue to code and pray.
Indeed it feels random to me when this occurs:
sometimes I only change 1 thing and save and then it's immediately read-only,
well in other cases it will let me edit several things until it is stuck.
Someone else also experiencing this and maybe got a tip?
Maybe I hit some magic hotkey or something?
My bad, please check if your projects folder is not a synchronized one, so when you edit (change) your project, the backup tool starts to update in remote location for synchronization purposes, so locks the file.
The answer to this problem is most likely that you are currently in Debug mode - i.e. the application is being run. Click "Stop" and it'll allow you to edit the files again.
By default, you cannot edit source files while the Debugger is running.
Is it normal for Intelli J to take a lot of time (almost 12 hours) to update indices for a project? I just installed Intelli J on my machine and imported a rather large Maven project (13k+ files).
I understand that the project is large but I let my computer up all night and when I woke up in the morning, Intelli J still hasn't finished updating the indices for the files yet, which makes it impossible to do anything since the popup with title 'Updating Index' keep hanging there in the middle of the screen.
There are several answers in the Forums for different IntelliJ Versions, here is what I´ve tried (IntelliJ 13).
Give more Memory. Does not help anything with the 'Updating indices'
Delete .idea and iml in project. Does not help.
In the end what resolved my problem with 'Updating indices' was:
delete 'caches' folder in user/.IntellIJIdea13/system/
I tried deleting the cache and it works perfectly. Thanks for the solution friends.
Just:
Open IntelliJ IDEA
Select the File menu
Select the Invalidate Caches / Restart... menu.
Once selected you get a pop-up with a bunch of options.
Select Invalidate and Restart
and before doing that make sure you saved all your changes else it might delete some unsaved changes.
Once you hit that, IntelliJ will restart and then you can see that all the indexing is done really fast.
Delete caches in library folder
rm -rv ~/Library/Caches/IdeaIC15/caches/
On Mac OSX the location of cache is ~/Library/Caches
In Intellij 2020.2 I faced this problem too. Restart/Invalidating cache didn't work for me. What I did was just deleting the cache folder in the following path:
C:\Users\davoud\AppData\Local\JetBrains\IntelliJIdea2020.2
I was able to solve this by going to File -> Invalidate Caches / Restart
Then on the dialog that opens select "Invalidate and Restart"
I had the same problem with IntelliJ 2017.2.3 - i.e. my project would keep updating indexes over and over again.
I discovered that I had gone over my disk quota in my home directory. By default IntelliJ stores the indexes in the home directory like this:
~/.IdeaIC2017.2/system/index/
The solution for me was to:
Quit IntelliJ
Move the whole .IdeaIC2017.2 directory to another
mount which has more space:
mkdir /space/ideaConfig
mv ~/.IdeaIC2017.2 /space/ideaConfig/IdeaIC
Update bin/idea.properties to point at the new index/config location:
idea.config.path=/space/ideaConfig/IdeaIC/config
idea.system.path=/space/ideaConfig/IdeaIC/system
It is possible that some of the other answers to this question were due to the same problem and were inadvertently fixed by "deleting caches folder", "invalidating caches" etc which would have potentially freed up enough disk space to build the indexes.
Though the accepted and other answers may fix a particular problem, I have found that the problem with very long indexing times often comes from the fact that a repository contains or links to some directory that contains a large number of files. Often this is done for testing and the directory in question is not actually part of the project, e.g. ignored by the VCS.
The IDE does not automatically ignore those directories when indexing, but it is possible to "exclude" the directory from the project. This will prevent indexing as well.
the easier way is as follow:
file --> settings --> (uncheck) Synchronize files on frame or editor tab activation.
I guess Idea is more collecting garbage than doing useful work. Use G1 GC instead of the default.
Help -- Edit Custom VM Options
-XX:+UseG1GC
instead of
-XX:+UseConcMarkSweepGC
and of course restart Idea.
Downside: G1 tries to collect garbage before stopping the process. This is insane, but this is what it does. For a program with 16G of heap, cleaning-up took 27 minutes. So do not configure your Idea to use a 16G heap.
you can manually exclude file or directory withIDEA Indexing, it can improve file load speed.
some files are generated dynamic， we don't need index these files every time when we start IDEA.
"Invalidate Caches.." always works for me.
So, for all of you that are still in pain because of this when using Windows (with or without WSL) you can try this:
https://youtrack.jetbrains.com/issue/IDEA-293604/IntelliJ-is-hanging-during-build-process-and-indexing-process-when-working-on-the-WSL-projects.#focus=Comments-27-6427409.0-0
Windows defender can be very demanding with these things. Excluding idea64.exe process just made everything fast again for me.
probably - old bug in caching system. it happens in ALL versions, especially if you upgrade your version of IntelliJ or JDK.
To fix it:
1) close the GUI.
2) go to %HOME_DIR%.IntelliJIdeaXXXX\system\caches and delete it
3) start the the GUI again.
~/Library/Caches/JetBrains/IntelliJIdea2021.1
it's works for me..
IDEA 2020.2
Right click folder under the Project, then mark as Exclude to exclude folder that you don't want to index
I have a VS solution containing several projects. While debugging a particular project all the source files are locked by VS. I would like to unlock sources that the debugee doesn't have dependency on. Is there any way to do this within one solution?
UPDATE:
I'm using Win XP SP3 32bit. Visual Studio 2010, C#. Edit and Continue is enabled. The solution contains 6 projects (number in not important actually), 5 of them depend on the data access layer project which uses Entity Framework. None of the 5 have any mutual dependencies. They are WinForms and Console applications. I would like to be able to run one of the projects and make changes to others without stopping the first. The problem is starting and stopping the project take considerable amount of time.
The Edit and Continue feature is preventing you from editing files if the debugger hasn't stopped the program. The simple workaround is Debug + Break All, you should then be able to edit the files, your changes will be immediately effective provided your changes do not violate the restrictions imposed by E+C. This is the most efficient work flow.
The heavy-handed approach is to disable Edit and Continue. Tools + Options, Debugger, Edit and Continue, uncheck the Enable check box.
I don't think that there is a way to avoid that. While debugging Visual Studio lock all files to prevent any change on them, including those on other projects.
You can try to open the project which you are interested on with another Visual Studio instance to make changes to your files or open files singularly with another editor.
This doesn't quite answer the OP's question per se, but for anyone who has stumbled upon this page in the same (very frustrated) boat as I am, this might help.
The solution: start without debugging.
It was driving me absolutely crazy that Visual Studio would not let me edit files while the app was running. My typical workflow is:
Make some changes
Run the app to see the effects of those changes
Based on the results, make more changes, etc. etc.
The problem is Visual Studio was preventing me from step 3. It demands that you STOP running the app before you can even make any changes (including to a XAML file or adding a file to the project), which also means that you can't go back to the app to double-check something while you are actually programming it at the same time (which is how I work, bro).
Thank god I finally discovered if I run without debugging it doesn't impose this ridiculous limitation. It's still a pain in the butt if you actually need to debug something you have to re-run the app in debug mode, but it sure beats having to kill the app before it will even let you edit a file.