You need to log in before you can comment on or make changes to this bug.
Product Version: NetBeans IDE Dev (Build 20071019101049) Java: 1.6.0_02; Java HotSpot(TM) Server VM 1.6.0_02-b05 System: Linux version 2.6.20-15-generic running on i386; UTF-8; en_US (nb) I do not understand how the version control in ide works or how the mercurial plugin works (I mean caching etc.) but there must be something wrong. I do not understand why Mercurial > Status command takes about 2 minutes on a repository with cca 600 classes when command line command 'hg status' is so quick. The similar for commit. I think it downgrades main benefit of a distributed version control system - speed.
Can you attach the project you are seeing this on so we can test it. What steps did you take? Initialize Mercurial Repository, then Status? Are you listing all 600 files in the Status?
It is internal project of sun. If you are sun employee i can send you the repository path. The project is a free form project containing another subprojects - several j2se libraries, one web project and one nb project. I have made changes in about 10 classes. I usually mount a cloned repository in favorites view and invoke Mercurial > Status to check uncommitted changes.
Yep I'm in sun can you send me the link: john dot rice at sun dot com
I've been looking into this and have found the issue. The problem is that when you had a large number of new files that where not in the cache the Status call was resulting in an external Hg call for each file to fetch it's status. I've code I'm testing which removes this problem and drops down the initial Status display to a few seconds. Essentially I'm just making one Hg call to get all the status values for the entire repository and passing these values down into refresh cache calls so further low level hg calls are not required. I will reuse the same technique to optimize scanFolder, which could have the same problem if you have a large number of new files in a single folder and you open that folder in Project or File view.
I've optimized the number of hg calls required when bringing up the Status Window if you have a large number of locally new files not yet in the cache. You should see a significant difference in your test case of 600 files. On my machine this is displaying in a few seconds or less. Can you confirm this in your environment. Now that the excessive hg calls have been tackled, I'm looking into excessive calls against the cache itself in refreshCached, which is now dominating the timings. I will use similar techniques to optimize this and see if it helps further.
Changes committed to head for excessive hg call issue. Still working on excessive cache lookups.
On further investigation turns out most of the hit was coming from debug code, when the debug flag was turned off and the code profiled, refreshCache was not even appearing. Closing the issue, reopen if you find any other slow commands.
Show Status has acceptable speed now. Verified.
