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 144109

Summary: Intrusive Automatic Processing
Product: editor Reporter: willfarnaby <willfarnaby>
Component: Parsing & IndexingAssignee: Vitezslav Stejskal <vstejskal>
Status: RESOLVED FIXED    
Severity: blocker CC: dbalek, dstrupl, jjancura, johnjullion, twolf2919
Priority: P2 Keywords: PERFORMANCE
Version: 6.x   
Hardware: All   
OS: All   
Issue Type: DEFECT Exception Reporter:

Description willfarnaby 2008-08-15 18:29:36 UTC
When the user is conducting (and waiting for completion of) a processing-intensive / critical workflow path /
long-running task (e.g., Replace in Files...), then NetBeans should not begin/continue automatic processing (e.g.,
auto-deploy of J2EE applications / components to GlassFish or other app server). Rather, such CPU-intensive automatic
processing tasks should simply be scheduled for _after_ the explictly user-initiated task completes.

This would definitely enhance the usability of NetBeans.
Comment 1 Tomas Danek 2008-08-27 12:19:56 UTC
Please specify concrete problem in some area you see, so that this can be addressed..
Comment 2 willfarnaby 2008-08-27 21:54:09 UTC
Well, I did specify a concrete example in my original log entry: "(e.g., Replace in Files...)".

When I, the user, initiate (for example) "Replace in Files..." operation, and it takes 10 minutes to finish its display
of replacement candidate nodes in its output window because "Scanning..." or "Deploying..." or some other NetBeans
background activity is occurring... that's a productivity killer.
Comment 3 Petr Dvorak 2008-10-09 13:40:40 UTC
I understand this issue is about preferring user's CPU intensive tasks to netbeans's tasks... Reassigning to performance
for further evaluation.
Comment 4 willfarnaby 2008-10-12 22:16:53 UTC
Latest dev build (although I invariably find NetBeans killing productivity with its deadly so-called "background"
processing, no matter what the particular build).

The latest (now apparently infinite wait) started with "Refreshing Workspace..." in the statusbar, and later on "Please
Wait, classpath scanning in progress..." dialog appeared.

See attached thread dump.

Is there any possibility that the NetBeans developers can dedicate a couple of months to _ONLY_ fixing the
productivity-killing, insanely-aggrevating waiting that NetBeans imposed on its users? If MyEclipseIDE and Visual Studio
can be perceptively snappy, why can't NetBeans. To be blunt, this infinitely tedious imposed waiting is just about to
drive me away from NetBeans for good.
Comment 5 twolf2919 2009-05-27 15:34:43 UTC
I changed this to a defect and a P2 - because it, along with all the other bugs that have been reported against
scanning, it kills productivity.

My latest observation (valid on all recent daily builds up to and including the 5/27 build): on my freeform project with
3800 java source files and about 70 3rd-party libraries, *whenever* I do a "Clean and Build Main Project", I patiently
wait 40-50 seconds for the whole project to rebuild.  No problem - that is expected.  But if I then hit "Run Project", I
invariably get "Please wait, classpath scanning in progress..." for the next minute or so.  WTF?  I just built the
project from scratch - why can't I run it???  The friggin' "classpath scanning in progress" is taking longer than the
entire build!
Comment 6 Jesse Glick 2009-05-28 15:59:33 UTC
twolf2919 - Run Project on a _freeform_ project should never open a "Please wait, classpath scanning in progress..."
dialog; it should run your configured Ant target immediately. Are you positive you are not running a regular Java SE
project (i.e. IDE-managed build script)? If you can reproduce this, please file a separate bug in component 'java',
subcomponent 'freeform' with as many details as possible.
Comment 7 twolf2919 2009-05-28 16:12:38 UTC
@Jess, you're absolutely right - it's *not* a freeform project.  It's a "Java Project with Existing Source".  Sorry
about that.
Comment 8 David Strupl 2009-06-02 15:58:36 UTC
Dusan, Vita, can you comment on this?
Comment 9 David Strupl 2009-06-03 10:15:53 UTC
Planning for 6.8.
Comment 10 Vitezslav Stejskal 2009-06-04 10:24:25 UTC
I filed the problem with running j2se projects blocked by indexing as issue #166527.
Comment 11 Vitezslav Stejskal 2009-10-15 11:48:51 UTC
The replace-in-files/projects now wraps all their changes in an atomic action allowing the listeners to process all
events in one batch. #166527 is fixed as well, plus many other changes.

http://hg.netbeans.org/jet-main/rev/42b96088117f