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.

Bug 193521 - Allow canceling scan after startup
Summary: Allow canceling scan after startup
Status: NEW
Alias: None
Product: editor
Classification: Unclassified
Component: Parsing & Indexing (show other bugs)
Version: 7.0
Hardware: All All
: P2 normal (vote)
Assignee: Tomas Zezula
Depends on:
Reported: 2010-12-16 21:30 UTC by Petr Jiricka
Modified: 2010-12-21 11:11 UTC (History)
1 user (show)

See Also:
Exception Reporter:

Profiling snapshot during up-to-date check after startup (247.32 KB, application/octet-stream)
2010-12-17 21:45 UTC, Petr Jiricka
messages.log attached (180.79 KB, text/plain)
2010-12-20 13:07 UTC, Petr Jiricka

Note You need to log in before you can comment on or make changes to this bug.
Description Petr Jiricka 2010-12-16 21:30:28 UTC
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:, 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.
Comment 1 Tomas Zezula 2010-12-16 21:45:21 UTC
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.
Comment 2 Petr Jiricka 2010-12-16 22:05:43 UTC
Thanks for the insights - sounds like there are some obstacles, but these are solvable, and overall this enhancement would be useful.
Comment 3 Tomas Zezula 2010-12-17 08:03:55 UTC
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.
Comment 4 Petr Jiricka 2010-12-17 21:45:31 UTC
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.
Comment 5 Tomas Zezula 2010-12-20 10:40:08 UTC
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.
Comment 6 Petr Jiricka 2010-12-20 13:07:48 UTC
Created attachment 104311 [details]
messages.log attached
Comment 7 Tomas Zezula 2010-12-20 17:08:05 UTC
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.
Comment 8 Petr Jiricka 2010-12-21 10:57:33 UTC
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.
Comment 9 Tomas Zezula 2010-12-21 11:11:48 UTC
But if it happens to you that the up to date takes long time please attach at least the log.