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.
Currently, NetBeans already allows you to cancel scanning after switching back to NetBeans from another window. Also, when you install the scan on demand plugin: http://wiki.netbeans.org/ScanOnDemand, the IDE does not scan sources after startup. However, this is still an experimental autoupdate feature. However, I think this is a generally useful capability that should be available in the standard distribution: sometimes everyone is in the situation when (s)he knows that "I haven't made changes to the source since I was running the IDE last time, so I don't need the IDE to rescan the sources". So I suggest that: in the situation when I am starting the IDE with some open projects whose sources were scanned before, the IDE allows the user to cancel the scan after startup. With this enhancement, I believe the Scan on Demand plugin will become obsolete.
As far as I know the scanning is not cancelable at all. Checking for external changes has nothing in common with scanning. I agree with "I haven't made changes to the source since I was running the IDE last time, so I don't need the IDE to rescan the sources" but if you did changes and you don't realize it two things may happen. 1st) the dependent modified projects will provide wrong data and user will report it as a bug (currently we close such issues when SOD is enabled) but we can detect it even in cancel case, not big problem. If there is lots of modified sources in the source root the OOM will happen as the ClassReader will prefer sources. Probably some check forcing the scan is needed to prevent this as letting the IDE die fast by OOM is not very good solution.
Thanks for the insights - sounds like there are some obstacles, but these are solvable, and overall this enhancement would be useful.
Not at all. There were times when the up to date check used to be fast. Now it seems to me that it's not true anymore, but I cannot say as I've installed the antivirus which affects the IO significantly. I will do some measurement on my old computer.
Created attachment 104235 [details] Profiling snapshot during up-to-date check after startup I tried on a computer without an antivirus, and here are the results for the famous web.jsf project: Scan/indexing after opening the first time: about 20 minutes Scan/up to date check after IDE restart: about 10 minutes So the up to date check is still very slow. I am attaching a profiles snapshot taken during the second scan.
Is the attached snapshot really from the second start when there were no modifications? If so, do you have the messages.log from this start. The IDE does lots of compilation in this start. Thanks
Created attachment 104311 [details] messages.log attached
Hele Petre, are you sure that the log is from the same run as the attached nps file? In the nps file there is intensive compilation while in the log there is no file compiled at all.
Sorry, you are right. Now I am trying again, and the up to date check takes only 1.5 minutes or so, and no compilation is happening. Still, my original request holds - I think it would be useful if I was able to cancel the up-to-date check.
Sure. But if it happens to you that the up to date takes long time please attach at least the log.