Webstorm git operation is very slow for win10!

Answered

For win10, git operations is very slow, but use git-bash is not.

2
27 comments

Please can you elaborate on this? Does it only happen when running Git from the IDE? Are git commands slow when you run them in your system terminal (cmd.exe?)

Please try taking CPU snapshots when the problem occurs (https://intellij-support.jetbrains.com/hc/en-us/articles/207241235-Reporting-performance-problems) and create a new support ticket (or a new issue in https://youtrack.jetbrains.com/issues/IDEA), providing the snapshots, idea.log and detailed problem description

0

I try to use cmd.exe in win10, but it is fast, it spend 1-2s while webstorm spent 10-11s

1

Any progress?

0

Can't see any snapshots requested above

0

@Elena Maybe you can try to checkout a git big web SPA project in Windows with many branches, open a few file tabs, and update a few remote files, then try to use context menu to git pull and switch branches. The IDE will get stuck for a while.

But when I run git pull in git-bash or tortorise git or cmd outside webstorm, it will be much faster.

0

Hi ! I'm experiencing the same problem, and opened a support ticket, added logs and automatic thread dumps, because I was not able to start the CPU profiler.

https://intellij-support.jetbrains.com/hc/en-us/requests/2461380

Please let me know if you need more info!

0

Not usable with bit git project,  takes forever to index 

0

Lucasdcavalcante As wee discussed in ticket, the issue in your case has been caused by custom plugins (Gitflow on the first place, and Gittoolbox) 

Daweiwang Gatekeeper Please send thread dumps and CPU snapshots to support: 

https://intellij-support.jetbrains.com/hc/articles/206544899
https://intellij-support.jetbrains.com/hc/articles/207241235.

0

I'm having the same issue. I have disabled all GIT related plugins.  See WI-55447 for diagnostic 

0

Noticed that upon opening project it runs git status command as following:

 

git -c credential.helper= -c core.quotepath=false -c log.showSignature=false status --ignored --procelain -z --

 

The "--ignored" flag, ignores git ignore settings, for big js project, the compiled output and node_modules directories can contain tens of thousands of files easily.

Also if you use npm link or pnpm(which uses links too), it will make it worse.

 

 

0

Konstantin Annikov, please see my previous comment about --ignored flag, when do git status check.

0

@Daweiwang Gatekeeper

The status is called with --ignored flag to properly highlight all ignored files in the IDE. This call is there since 2019.1 - https://youtrack.jetbrains.com/issue/IDEA-60354

Moreover, this call is called on a pool thread and should not prevent any other operation.

Note that the --ignored flag only instructs git to lists ignored path. Normally, git only lists that paths to ignored folders and does not traverse them. The output should be like this:

On branch more_branch_actions
Your branch is ahead of 'origin/ds/Branches-Actions' by 1 commit.
(use "git push" to publish your local commits)

Ignored files:
(use "git add -f <file>..." to include in what will be committed)
.DS_Store
.idea/Intellij-WT.iml
.idea/shelf/
.idea/workspace.xml
bin/hs_err_pid27721.log
bin/jbr_err_pid27721.log
build/jdk/
community/.DS_Store
community/build/dependencies/.gradle/
community/build/dependencies/build/
community/plugins/.DS_Store
community/plugins/maven/maven3-server-common/lib/
community/plugins/maven/maven36-server-impl/lib/
community/plugins/terminal/resources/.zsh_history
config/
out/
plugins/.DS_Store
system/
test-system/

Seems in your case gitingore rules are too complex or some files within ignored folders are force-added to git, which makes git to go through all the files and list them in the output. Please check if there is something incorrect in the gitignore, or maybe some files from ignored folders are unnecessary checked to git.

Alternatively, you can disable highlighting of the ignored file in the IDE. Note that ignored files will not be recognized as ignored in this case but as regular non-modified files. To do so, disable the git.process.ignore option in the IDE registry. ( Help - Find Action - Registry...)

 

1

@Dmitriy Smirnov I'm experiencing much the same thing; after every VCS action VCS just hangs for minutes, massively out of date with the command line.

In the logs it seems to tie up with calls to `git status --ignored`.

From the command line `git status --ignored` takes 90+ seconds. I have a very simple .gitignore, but I do have an enormous ignored node_modules directory, and I'm fairly sure git is recursing the whole way through it, not stopping when it finds it. I have run git with all tracing options turned on, but no useful data.

I have no force added ignored folders that I can see.

WIndows 10, git 2.29.2.windows.2

It's rendering IntelliJ close to unusable.

0

Robert Elliot

git should not traverse the ignored folder if there is no reason for that. If ti does so - then that's some git bug.

As the comment above says, you can disable ignore processing so IntelliJ will not call the status with --ignore flag

0

What's your source for "git should not traverse the ignored folder if there is no reason for that"? I can't find anything saying that here:
https://git-scm.com/docs/git-status

Yes, disabling ignore processing has worked for me. But that's after several months of irritation, and spending several hours today searching for this solution. Other members of my team have the same problem. Most are just blaming Jetbrains.

If you're calling git with arguments that make it prohibitively slow I don't think it's enough to just shrug and call it an upstream bug.

0

Just tried it with a completely clean, new git project, one entry in .gitignore to ignore the node_modules dir and copied over my huge node_modules dir.

Takes 90 seconds to do a git status --ignored from the command line.

The git interaction with the file system does seem to be very slow, but I can see the same symptom on my mac, just much faster - git status --ignore takes twice as long if an ignored dir has twice as much data in it. It's just still fast enough not to be an issue in the end.

0

On macOS - ignored directory has one tiny file:

$ GIT_TRACE_PERFORMANCE=2 git status --ignored
18:35:51.028356 read-cache.c:2297 performance: 0.000054000 s: read cache .git/index
18:35:51.028770 read-cache.c:1609 performance: 0.000017000 s: refresh index
18:35:51.029055 diff-lib.c:249 performance: 0.000006000 s: diff-files
18:35:51.029498 unpack-trees.c:1657 performance: 0.000008000 s: traverse_trees
18:35:51.029510 unpack-trees.c:411 performance: 0.000002000 s: check_updates
18:35:51.029516 unpack-trees.c:1744 performance: 0.000028000 s: unpack_trees
18:35:51.029520 diff-lib.c:529 performance: 0.000099000 s: diff-index
18:35:51.029624 name-hash.c:600 performance: 0.000009000 s: initialize name hash
18:35:51.029770 dir.c:2781 performance: 0.000183000 s: read directory
On branch master
Ignored files:
(use "git add -f <file>..." to include in what will be committed)
src/

nothing to commit, working tree clean
18:35:51.030017 trace.c:487 performance: 0.002292000 s: git command: git status --ignored

And then with 1.1G of files in 47,827 files and directories in the one ignored directory:

$ GIT_TRACE_PERFORMANCE=2 git status --ignored
18:36:28.670397 read-cache.c:2297 performance: 0.000053000 s: read cache .git/index
18:36:28.670807 read-cache.c:1609 performance: 0.000017000 s: refresh index
18:36:28.671090 diff-lib.c:249 performance: 0.000006000 s: diff-files
18:36:28.671531 unpack-trees.c:1657 performance: 0.000008000 s: traverse_trees
18:36:28.671542 unpack-trees.c:411 performance: 0.000001000 s: check_updates
18:36:28.671548 unpack-trees.c:1744 performance: 0.000027000 s: unpack_trees
18:36:28.671552 diff-lib.c:529 performance: 0.000099000 s: diff-index
18:36:28.671654 name-hash.c:600 performance: 0.000012000 s: initialize name hash
18:36:29.070224 dir.c:2781 performance: 0.398607000 s: read directory
On branch master
Ignored files:
(use "git add -f <file>..." to include in what will be committed)
src/

nothing to commit, working tree clean
18:36:29.070633 trace.c:487 performance: 0.400852000 s: git command: git status --ignored

Notice it takes 2,178 times as long, despite the only difference being files in an ignored directory.

If this is a git bug (and since it's present on windows and macOS in the latest version I'm not convinced it is), it's one you need to work around, because on a slow disk / file system it's a disaster.

0

Hi, 12.04.2021 issue still exist. Solution to turn off git.process.ignore works well. (Win10, Webstorm 2021.1, git 2.31.1.windows.1)

1

thanks, @Marek_Mazurkiewicz, it works, but how did you discovered the solution, it isn't an obvious one 

0

Work around: Rename runnerw.exe and runnerw64.exe to other names.

1

I'm googling it for some hours now and I always find the same: no support from Intellij but instead some hacks or workarounds. Why is the QA from Intellij not fixing this?

INFO -  #git4idea.commands.GitHandler - git push took 36646 ms

This is very bad and obviously a PhpStorm issue in my case. Using a git software like Fork only takes 4 seconds to push or so.

@Marek Mazurkiewicz @Alexander Zonov where do I set this flag? How did you turned off the ignore process? 

I can't find it in the Registry anymore.

The rename of runnerw.exe did not work and only spams the Log file to a big file size.

1

@I-b, I believe, I used "shift+shift" search for `registry` back then. Thought I don't see such option within the Registry anymore.

0

Yes, unfortunately this option does not exist anymore 😥

Why got this removed from the Registry @Dmitriy Smirnov ?

0

This registry key has been moved to Preferences | Advanced Settings and now it's called "Highlight ignored files", so you can disable it.

0

Ah, great, thanks.

Even with that setting disabled pushing something takes longer than in the Fork software, but it's better at least and I just read some news meanwhile...

0

I've also had this problem. What worked for me is:

Invalidate IDE cache and then

git prune
git gc 
0

Please sign in to leave a comment.