This Bugzilla instance is a read-only archive of historic NetBeans bug reports. To report a bug in NetBeans please follow the project's instructions for reporting issues.
Build: NetBeans IDE 7.4 (Build 201310111528) VM: Java HotSpot(TM) 64-Bit Server VM, 24.0-b56, Java(TM) SE Runtime Environment, 1.7.0_40-b43 OS: Windows 7 User Comments: GUEST: Slowness on opening files... pkevin: Doing a build of a web service to deploy to Glassfish server. Building the war file is taking forever. Maximum slowness yet reported was 46654 ms, average is 35306
Created attachment 143310 [details] nps snapshot
The data systems are doing save in the EDT causing fileChanged to be invoked in EDT and single call of URLMapper.findFileObject took 35s.
The first problem is that o.n.m.git.ui.actions.GitAction.performAction() calls o.n.core.NbLifecycleManager.saveAll() in EDT. The second problem is in o.m.parsing.impl.indexing.RepositoryUpdater$FCL.fileChanged(), which performs a lengthy operation in the thread that performs the saving. It can make committing of changes quite slow. Can you please, Tomas, consider rescheduling it using e.g. request processor? Thank you.
I just want to point out that the lengthy operation is a single call of URLMapper.findFileObject() taking more than 1/2 minute. :-) Doing it asynchronously may be possible but complicated as all the changes define ordering. Braking ordering will cause nondeterministic parsing.
I can (and i should probably) save files in git in a background thread, but the fact that the whole process of handling file's modification takes so much time means that for example after calling Git -> Commit... user will have to wait for these 30 seconds anyway before the commit dialog is shown which seems wrong too.
(In reply to Tomas Zezula from comment #4) > I just want to point out that the lengthy operation is a single call of > URLMapper.findFileObject() taking more than 1/2 minute. :-) The method calls FileUtil.normalizeFile, which needs to touch touch the disk. If you are sure that the file is normalized, we might try to skip the normalization. On the other hand, if the disk is stuck while calling FileUtil.normalizeFile, it would be probably stuck while performing the actual commit anyway. So fixing this particular part will not make the committing significantly faster.
> So fixing this particular part will not make the committing significantly faster. This is not happening while committing but immediately after user clicks on Git -> Commit... so even before he gets any UI indication (commit dialog opens) so it will just look nothing is happening.
Moving the whole save into background. If you decide to make any changes in FS or Indexing regarding this issue, reopen and reassign to yourself. fix: http://hg.netbeans.org/core-main/rev/bf9453b433c6
Yes, the URL came from the FileObject just to prevent to keep reference on FileObject. Anyway I am trying to reschedule the fileChange when it comes from EDT.