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.
Summary: | Intrusive Automatic Processing | ||
---|---|---|---|
Product: | editor | Reporter: | willfarnaby <willfarnaby> |
Component: | Parsing & Indexing | Assignee: | 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
Please specify concrete problem in some area you see, so that this can be addressed.. 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. I understand this issue is about preferring user's CPU intensive tasks to netbeans's tasks... Reassigning to performance for further evaluation. 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. 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! 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. @Jess, you're absolutely right - it's *not* a freeform project. It's a "Java Project with Existing Source". Sorry about that. Dusan, Vita, can you comment on this? Planning for 6.8. I filed the problem with running j2se projects blocked by indexing as issue #166527. 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 |