Intelli J IDEA takes forever to update indices - maven

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

Related

How to recover files after getting permanently deleted

So recently, all files of a python project which I had been working on for weeks got accidentally deleted, and then I emptied my recycle bin, so it is gone now.I tried to "Restore Previous Versions" of the folder it was in in windows, but it said that there were no previous versions. So I tried using a disk drill to recover those files, but i could not even find them in the list of files that it came up with. So is there a different setting/configuration on disk drive which could be preventing me from recovering those files? Do I need to use another recovery software?Or is it going to be hard/impossible to recover the file? I have been working on this project for a long time, so any help would be hugely appreciated
If you do this on VSCode while using GIT. Recreate the file in the location you deleted it, then right click on the file and select file history. You should be able to restore most, if not all, of your data.
Just happened to me, figured this might help someone else in the future.
If you don't have any shadow copies to restore a previous version from, then speicalized undelete tools are your only hope. However, if the sectors containing the deleted files' contents have been overwritten since deleting them there is a chance all is lost.

How to make live-server stop refreshing when nothing changed

I love live-server as a tool for auto-updating a project when changes are made, but I can't bare to use it anymore because it just refreshes WAY too frequently (about every 10-15 seconds) on my Mac.
I can't find what's changing or even IF any files are actually changing. I thought it might be detecting .DS_Store but looking at those files, none of them have a modified time late enough to be the culprit. The verbose logs just show that almost all of my folders in the project changed all at once. All I know for sure is that I'm not manually changing anything.
Anyone have any ideas or even suggestions for a "better" reload-on-change CLI option?
The issue appears to have to do with the fact that I'm using a network shared drive with live-server. If I move the project to my local machine, the problem goes away.
You can try https://www.npmjs.com/package/nodemon
It allowes you to add the Argument
--ignore ...
To ignore files or a whole Directory

Xcode build products folder won't change to Unique

I don't recall having this problem before I migrated to my Retina MacBook Pro, but since doing so, my projects have insisted on loading in the "old" development location. In years past, before XCode 4, we put all our products in /Development/Products. And, after migrating to the new MacBook Pro, they're going back there again. I can use 4.3 or newer and see the same problem with both, so I'm assuming it's some kind of configurable that's at work here.
Of course, the first thing I did was verify that the Preferences/Locations was set to Build Location = Unique. I confirmed this both in the GUI and by popping open the .plist to check the value of IDEBuildLocationStyle and it was set to Unique.
I tried removing my existing configuration files (everthing in ~/Library/Preferences/ named Xcode) and that succeeded in changing the behavior to putting the output in the build directory of the project itself (really not helpful in my world as I have complex multi-project workspaces). Quitting and checking the settings, they were set for IDEBuildLocationStyle=Unique.
So, I copied the working configuration from another machine I had to this one. Since it too had previously had the /Development/Products destination, but had subsequently been moved to the Unique build style, I expected that to work. It did not. It instead returned the output to /Development/Products.
Thinking it might be something with my Xcode install, I created a new user and built from the same source tree (not a duplicate, not a copy, the exact same files). In this case, the output went to the right place (unique subdirectory of the Derived Products for that user). So, I blew away the ~/Preferences/*Xcode* again and copied in the preferences from the new user. Unfortunately, this took us back to the same behavior that the uninitialized configuration had, which is to say building in the build directory of the project itself.
I restored to my backup configuration files, and now I'm back to working at /Development/Products, but this isn't a good long term solution.
When checking the script output for a test script, I can clearly see that somebody is setting SYMROOT to /Development/Products in the case of the older config, and build in the case of the default configuration file.
Clearly there's something here on this system that's influencing the configuration, but I cannot figure out what it is. Any assistance would be highly appreciated!
Also - When I try to use option-Clean to enable Clean Build Folder, it is never enabled, which makes a certain kind of sense, but I thought it might be another data point.
I tried the solution in Strange behavior of Xcode Build Products Path under Build Locations and that had the same result as deleting the preferences: build products as children of the project directory.
Has anyone else seen such a problem? Have you found a solution?
Well, after a very long time of suffering through this on my laptop, I was finally able to track down the problem.
Inside of:
project.xcworkspace/xcuserdata/<user>.xcuserdatad/
there is a WorkspaceSettings.xcsettings file.
It contained a key BuildLocationStyle, which was set to UseTargetSettings.
Deleting the file and thus resetting this value allowed me to get both the Clean Build Folder... working and to get my project building correctly.
Hopefully this will help somebody else.

Recover deleted files from Xcode4

I am new to git and to Xcode, and mac in general, so here's my question
I accidentally added my whole desktop to a project i was working on. When I wanted to delete the files, Xcode asked me if I wanted to delete them from disk and I said yes. The problem is that the project itself was in a folder inside my desktop and it took out everything. I had not committed my changes in the git local branch. Is there any way to undo what I did?
I appreciate whatever help I can get.
If you have not committed, Git cannot help you bring back your project. You will have to look at other alternatives ( like TimeMachine if you had it setup? )
If anyone's experiencing trouble with this problem, I nearly went back in my project and changed everything all over again but then remembered that it may not have been legit deleted yet. That is all to say that you should CHECK YOUR TRASH first! I don't know why it didn't occur to me until awhile after I had accidentally deleted it, but I ended up finding it in the Trash, so I'm thankful for that. Hope I've saved someone a whole lot of trouble!
Stop using the HDD immediately. Get Data Recovery help. Top of the line Data Recovery services may charge 1K-3K but can do an amazing job. Worth trying if your job is on the line.
Also, don't lose heart. Doing it the second time (if it comes to that) will take much shorter time than the original one.

Deleting Derived Data from Xcode 4.2 project doesn't re-index project

Indexing, code completion, & coloring disappear from my projects on a fairly regular basis, usually right after I add a file. And then it returns hours or days later, usually for unknown reasons (I've tried keeping a record but it's pretty random). CMD-clicking on even known terms (like viewDidLoad: or NSLocalizedString) result in a "Symbol Not Found" error.
It happens with Xcode 4.2 (I believe it happened in Xcode 4.0.2, but not as frequent).
I have no build errors, warnings, or static analysis messages.
I've restarted Xcode.
I've tried turning precompile off.
I don't have a case where I've got a circular header file include/import.
It happens if I use gcc, LLVM, CLang (in whatever combo).
It happens if I use iOS 4.3 or 5.0.
I've tried deleting the "derived data.", and even only the Index/ path.
After deletion & re-build I see the .hmap file & .xcindex folder (filled with db.xcodeindexdb* files).
...but I can't get code-completion, symbol detection, or coloring back.
What else can I do? I sincerely appreciate the help.
Have you tried a clean install (sudo /Developer/Library/uninstall-devtools)?
I have exactly the same problem for one particular project. Following workaround works for me: apart from deleting Derived Data , I make an SVN update or revert any file of the project. If the project file itself is changed my Xcode displays wrong target ,so I close the project and re-open it and then indexing starts properly.
The most reliable way I've found to force re-indexing of the project is to change the build settings, specifically 'Run Static Analyzer' - I wish I had a real answer though.
This might seem like a silly response, but have you tried to repair file permissions under disk maintenance?
Your thread is old, but anyway...
Deleting the derived data folder helps me everytime. I have to do it quite regularly, which is very annoying. Your find the path in the xCode-Settings(cmd+,) in the locations-tab.
I just had this issue. What worked for me is clearing the derived data, then closing the project and re-opening it. It didn't reindex until I closed and re-opened the project. The project never compiled fully, so it didn't even have to finish building to work.

Resources