Skip to main content


Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Eclipse Projects » EGit / JGit » slowness in egit after recent upgrade
slowness in egit after recent upgrade [message #1761117] Sun, 07 May 2017 09:22 Go to next message
Mukarram Baig is currently offline Mukarram BaigFriend
Messages: 4
Registered: June 2014
Junior Member
Hello folks,

I recently upgraded to neon.3 and the latest egit plugin (4.7.0.201704051617-r). I have noticed that adding the files to index is taking a lot of time now (as compared to earlier). Looking at the jstack output of eclipse, it did point to this worker thread continuously working. Can you please confirm if this filesystem resource refresh is indeed intentional when the files are added to the index? I had seen this to be extremely fast in the past, and I wanted to make sure that this slowness is not because my underlying filesystem is not slow. I have some confidence that the underlying filesystem is not problematic because the git operations via command line are going through fine. I also see that the adding to index itself is done pretty quickly, but the staging view freezes till this worker thread finishes. Any help will be much appreciated. Thanks!

"Worker-9" #77 prio=5 os_prio=0 tid=0x00007f0570001000 nid=0x6680 runnable [0x00007f05776f4000]
   java.lang.Thread.State: RUNNABLE
        at java.io.UnixFileSystem.list(Native Method)
        at java.io.File.list(File.java:1122)
        at org.eclipse.core.internal.filesystem.local.LocalFile.childNames(LocalFile.java:101)
        at org.eclipse.core.filesystem.provider.FileStore.childStores(FileStore.java:110)
        at org.eclipse.core.filesystem.provider.FileStore.childInfos(FileStore.java:93)
        at org.eclipse.core.internal.localstore.UnifiedTree.getLocalList(UnifiedTree.java:348)
        at org.eclipse.core.internal.localstore.UnifiedTree.addChildren(UnifiedTree.java:140)
        at org.eclipse.core.internal.localstore.UnifiedTree.addNodeChildrenToQueue(UnifiedTree.java:246)
        at org.eclipse.core.internal.localstore.UnifiedTree.accept(UnifiedTree.java:112)
        at org.eclipse.core.internal.localstore.FileSystemResourceManager.refreshResource(FileSystemResourceManager.ja
va:974)
        at org.eclipse.core.internal.localstore.FileSystemResourceManager.refresh(FileSystemResourceManager.java:960)
        at org.eclipse.core.internal.resources.Resource.refreshLocal(Resource.java:1594)
        at org.eclipse.egit.ui.Activator$ResourceRefreshJob$1.run(Activator.java:519)
        at org.eclipse.core.internal.resources.Workspace.run(Workspace.java:2240)
        at org.eclipse.core.internal.resources.Workspace.run(Workspace.java:2267)
        at org.eclipse.egit.ui.Activator$ResourceRefreshJob.run(Activator.java:504)
        at org.eclipse.core.internal.jobs.Worker.run(Worker.java:55)


at a different point:
"Worker-5" #73 prio=5 os_prio=0 tid=0x00007f058c004800 nid=0x667c runnable [0x00007f0577bfa000]
[b]   java.lang.Thread.State: RUNNABLE
        at org.eclipse.core.internal.filesystem.local.unix.UnixFileNatives.lstat(Native Method)[/b]
        at org.eclipse.core.internal.filesystem.local.unix.UnixFileNatives.fetchFileInfo(UnixFileNatives.java:76)
        at org.eclipse.core.internal.filesystem.local.unix.UnixFileHandler.fetchFileInfo(UnixFileHandler.java:28)
        at org.eclipse.core.internal.filesystem.local.LocalFileNativesManager.fetchFileInfo(LocalFileNativesManager.ja
va:62)
        at org.eclipse.core.internal.filesystem.local.LocalFile.fetchInfo(LocalFile.java:159)
        at org.eclipse.core.filesystem.provider.FileStore.fetchInfo(FileStore.java:258)
        at org.eclipse.core.filesystem.provider.FileStore.childInfos(FileStore.java:96)
        at org.eclipse.core.internal.localstore.UnifiedTree.getLocalList(UnifiedTree.java:348)
        at org.eclipse.core.internal.localstore.UnifiedTree.addChildren(UnifiedTree.java:140)
        at org.eclipse.core.internal.localstore.UnifiedTree.addNodeChildrenToQueue(UnifiedTree.java:246)
        at org.eclipse.core.internal.localstore.UnifiedTree.accept(UnifiedTree.java:112)
        at org.eclipse.core.internal.localstore.FileSystemResourceManager.refreshResource(FileSystemResourceManager.ja
va:974)
        at org.eclipse.core.internal.localstore.FileSystemResourceManager.refresh(FileSystemResourceManager.java:960)
        at org.eclipse.core.internal.resources.Resource.refreshLocal(Resource.java:1594)
        at org.eclipse.egit.ui.Activator$ResourceRefreshJob$1.run(Activator.java:519)
        at org.eclipse.core.internal.resources.Workspace.run(Workspace.java:2240)
        at org.eclipse.core.internal.resources.Workspace.run(Workspace.java:2267)
        at org.eclipse.egit.ui.Activator$ResourceRefreshJob.run(Activator.java:504)
        at org.eclipse.core.internal.jobs.Worker.run(Worker.java:55)

Re: slowness in egit after recent upgrade [message #1761178 is a reply to message #1761117] Mon, 08 May 2017 15:25 Go to previous messageGo to next message
Mukarram Baig is currently offline Mukarram BaigFriend
Messages: 4
Registered: June 2014
Junior Member
I tried to work around the problem by trying to perform the add to index and commit via git-gui. Once I came back to the eclipse workspace, egit was immediately able to remove the files already committed from the staging view, but it still did freeze up the editor after a while, and on checking jstack, the workers were busy doing the refreshResource and index update. Adding this information here to see if it might help in identifying the underlying problem (I am still unsure if it is plainly a disk slowness on my side). Thanks!
Re: slowness in egit after recent upgrade [message #1761236 is a reply to message #1761178] Tue, 09 May 2017 09:41 Go to previous messageGo to next message
Thomas Wolf is currently offline Thomas WolfFriend
Messages: 576
Registered: August 2016
Senior Member
Maybe you're hitting https://bugs.eclipse.org/bugs/show_bug.cgi?id=500106 . Do you have any especially large/deep folder hierarchies in your Eclipse workspace in projects imported from git (even if excluded via .gitignore)?
Re: slowness in egit after recent upgrade [message #1761425 is a reply to message #1761236] Wed, 10 May 2017 23:34 Go to previous messageGo to next message
Mukarram Baig is currently offline Mukarram BaigFriend
Messages: 4
Registered: June 2014
Junior Member
Hi Thomas,

You are right, and I do have node_modules in two folders of my git repo. Each of these node_modules have about 40k files and they are marked via .gitignore. Is there a workaround in the interim? I tried to follow the bug #500106 , but a workaround was not evident (unless I am missing something).
Thanks for the reply!
Re: slowness in egit after recent upgrade [message #1763364 is a reply to message #1761425] Sat, 13 May 2017 15:41 Go to previous message
Thomas Wolf is currently offline Thomas WolfFriend
Messages: 576
Registered: August 2016
Senior Member
One work-around is to uncheck in Preferences->Team->Git the option "Refresh Resources when Index Changes".

The downside is that you'll have to refresh manually when you unstage a deleted file.
Previous Topic:egit shows ">" on all files in newly cloned project
Next Topic:How to do "submodule init" ?
Goto Forum:
  


Current Time: Thu Mar 28 19:52:29 GMT 2024

Powered by FUDForum. Page generated in 0.04623 seconds
.:: Contact :: Home ::.

Powered by: FUDforum 3.0.2.
Copyright ©2001-2010 FUDforum Bulletin Board Software

Back to the top