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.
At startup, the "scanning projects" task takes a very long and annoying time to complete. At times it takes more than 3 minutes on a Windows7/2.66 Ghz Quad core/4Gb ram PC. And until it's finished, code completion and file upload won't work.
On a typical scenario, the IDE has from 4 to 7 projects open, all of them on the C:\ hard drive.
Could you share the projects with us ?
(In reply to comment #2) > Could you share the projects with us ? I'm afraid I can't because they are owned by the company I work for, but if you need other info, please ask me and (if I can) I'll answer.
Following will be great: 1. your messages.log file (to know the details of your setup) http://wiki.netbeans.org/FaqLogMessagesFile 2. Self-profile snapshot of scanning of the project(s) create it vua those steps: start the ide with empty userdir(and cachedir if you are using the newest dev builds) activate all the clusters needed for your projects. Start self-profiling, open your projects, wait till all the scanning is finished, stop the self-profiling. http://wiki.netbeans.org/FitnessViaPartnership
Created attachment 121995 [details] My messages.log
How can I do self-profiling? If I select Profile->Attach profiler, there is no way (nor any reference) to "self profile" the IDE. I wish it could be simpler, both for users and for developers, to track bugs in Netbeans...
(In reply to comment #6) > How can I do self-profiling? See http://wiki.netbeans.org/FitnessViaPartnership - it is very simple.
Created attachment 121997 [details] Self profiling snapshot
~260s of the time spent in scanning is spent in native filesystem methods like java.io.WinNTFileSystem.getBooleanAttributes java.io.WinNTFileSystem.list java.io.WinNTFileSystem.getLastModifiedTime there are some possibilities what could have caused this (generally slow disc, antivirus, very fragmented filesystem, very very large project) can you please attach new messages log (it has to be from the time of the long scanning slowness otherwise there is nothing relevant in the log)
Created attachment 121998 [details] Messages log file
there seems to be disc access by parsing and subversion simultaneously, subversion guys please evaluate
I found another case of possible simultaneous disk access in bug 215792
Please run the IDE with -J-Dorg.netbeans.modules.subversion.level=500 and attach the messages log once the scanning finishes.
(In reply to comment #13) > Please run the IDE with -J-Dorg.netbeans.modules.subversion.level=500 and > attach the messages log once the scanning finishes. Where am I supposed to write -J-Dorg.netbeans.modules.subversion.level=500 ? Should I run it from the command line? Again, should I delete messages.log first? May I ask what this option does to both the IDE and the message log?
(In reply to comment #14) > Where am I supposed to write -J-Dorg.netbeans.modules.subversion.level=500 ? > Should I run it from the command line? Yes, in commandline, go to the install dir/bin and run 'netbeans -J-Dorg.netbeans.modules.subversion.level=500' > Again, should I delete messages.log first? no need, it will be overwritten in the var/log folder. Simply attach the latest one messages.log file. > May I ask what this option does to both the IDE and the message log? it enables more logging. The message log will be bigger. And we will see if subversion waits for the parsing to finish. Generally, subversion waits the first 180s of the initial parsing/scanning process and does not get in the way of the scanning. After 180 seconds it starts its own scanning no matter if the parsing of sources finishes or not.
Created attachment 122271 [details] Zipped messages.log file (with higher logging level)
hmm, the messages log does not indicate that subversion refresh has been delayed. Will try to tweak it.
fix: http://hg.netbeans.org/core-main/rev/fc1e8d83a60b - fixes also bug #211634
(In reply to comment #18) > fix: http://hg.netbeans.org/core-main/rev/fc1e8d83a60b - fixes also bug #211634 Sorry about my ignorance. Does that mean that if I download v7.1.2 and install it, this issue should disappear?
> Sorry about my ignorance. Does that mean that if I download v7.1.2 and install > it, this issue should disappear? No, the Target Milestone field for this issue is set for 7.3. That means the fix will be delivered in the 7.3 release and available in daily builds soon.
Created attachment 132197 [details] Self profiling snapshot Just got the same problem as before. Same machine, same OS.
And the installed version is the new 7.3 (In reply to comment #21) > Created attachment 132197 [details] > Self profiling snapshot > > Just got the same problem as before. Same machine, same OS.
looking at the snapshot i came to the following conclusion: for the first ~150s the only running RP is RepositoryUpdater.Worker and Git is successfully blocked. After that time the VCS subsyetem cannot wait any longer (there must be a time limit after which the VCS starts anyway) and the two tasks start competing for resources. So if i understand the snapshot right then it's probably indexing fault that it cannot finish in 2-3 minutes.
>if i understand the snapshot right thenit's probably indexing fault that it cannot finish in 2-3 minutes. This is wrong evaluation. According to snapshot most of the time is spent in the collecting the files to be scanned (FileObject.getChildren and checking for symlinks in fact File.listFiles) these operations are IO bound and are slowed down by the versioning. The 2-3 minutes arguments is a non sense as the time depends on projects size.
(In reply to comment #24) > The 2-3 minutes arguments is a non sense as the time depends on projects size. Then i guess i can introduce a switch for those having such big repositories and clock versioning indefinitely while the parsing is running.
fixed: core-main #84a819690420
Start with -J-Dversioning.delayscan.nolimit=true and versioning system status scan won't ever block the parsing. The drawback is that till parsing is running file vcs statuses won't be refreshed.
Integrated into 'main-golden', will be available in build *201303062300* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress) Changeset: http://hg.netbeans.org/main-golden/rev/84a819690420 User: Ondrej Vrabec <ovrabec@netbeans.org> Log: Issue #208185 - Scanning Projects takes more than 2-3 minutes to complete introducing a switch blocking status scanning indefinitely until parsing finishes