Product Version = NetBeans IDE 6.9 (Build 201006101454)
Operating System = Windows 7 version 6.1 running on x86
Java; VM; Vendor = 1.6.0_19
Runtime = Java HotSpot(TM) Client VM 16.2-b04
Created attachment 100160 [details]
several minutes scan dump
Created attachment 100161 [details]
another scan dump
Scanning not stopped on project close is a known problem - bug 177511 or bug 165093.
As for the scanning itself, according to the attached snapshots, most of time is just in crawling the project content, i.e. spent in file system calls to collect files and folders, nothing else significant. E.g. in the second snapshot that has 4 minutes, about 3 minutes are spent only in WinNTFileSystem.getBooleanAttributes.
How big is your project? For thousands of file it may take significant time to go through all of them, especially for the first time.
(In reply to comment #3)
> collect files and folders, nothing else significant. E.g. in the second
> snapshot that has 4 minutes, about 3 minutes are spent only in
AFAIK nothing fixable on NetBeans' site, it really seems that the FS has been very active. One idea - don't you have any ZIP file on your desktop? There used to be (or still is?) a bug in JDK which causes this method to be very slow I think...
Well it is a joomla installation - around 8000 files. I have some small zip files in it - from 1 to 2MB - around 10 files or so.
Created attachment 100511 [details]
This dump is taken while refreshing a folder with js files - around 80MB big
Created attachment 100522 [details]
21 000 files - 100MB project - 20 minutes scan
The point is that if scanning is inevitable, it should not put the IDE into a completely unusable state.
According the dump of refreshing a folder with js, the bulk time (57 seconds) is spent in getBooleanAttribute, which is native method. This native listener was corrected and one of the fix should also increase speed of this.
I'm losing this issue as wontfix, because the listener was changed and should now work better.