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.
This issue was reported manually by szmitek. It already has 2 duplicates Build: NetBeans IDE 7.3 Beta 2 (Build 201211062253) VM: Java HotSpot(TM) 64-Bit Server VM, 21.0-b17, Java(TM) SE Runtime Environment, 1.7.0-b147 OS: Linux User Comments: szmitek: Build C++ project during background sanning of project. Very long background scanning of projects Maximum slowness yet reported was 6612 ms, average is 5809
Created attachment 129350 [details] nps snapshot
One snapshot is SunToolkit.awtLock() - related, the second one is WDialogPeer.endModal()... Both came from Dialog.setVisible(). But what is interesting - both are initiated by ModalMsgDialog. Could it be a false slowness alarm?
Created attachment 129553 [details] Proposed patch How about this 'fix'? I would propose to use NB's ProgressUtils instead of ModalMessageDlg... I've left the API and behavior. But have questions regarding the behavior, especially whether the postEDT task should be executed after the main task cancellation or not. Please read the javadoc and comment.
Alex, Vladimir, I would like to get your comments... Thanks, =Andrew
semantic was changed, does not look safe to integrate now
Created attachment 129576 [details] Fixed patch
(In reply to comment #5) > semantic was changed, does not look safe to integrate now Not that I'm against the proposed changes, but I would appreciate if Vladimir was at least slightly more verbose... What exactly you do mean by "semantic was changed"? Is it about setting wasCancelled only if cancel() returned true vs. setting it once cancel button is pressed? Right this is a small change and I'm OK with Alex's change here. Or do you have some other things in mind? (In reply to comment #6) In this change semantic was really changed if compare to the original state. # 1 API was changed # 2 postEDTTask is invoked in tests-mode ONLY # 3 (even if fix this, I guess, typo) now LongWorker's doPostRunInEDT() is started only if the doWork() was not cancelled (which was not the case before). Thanks, =Andrew
(In reply to comment #7) > (In reply to comment #5) > > semantic was changed, does not look safe to integrate now > > Not that I'm against the proposed changes, but I would appreciate if Vladimir > was at least slightly more verbose... sorry for that. > > What exactly you do mean by "semantic was changed"? Is it about setting > wasCancelled only if cancel() returned true vs. setting it once cancel button > is pressed? Right this is a small change and I'm OK with Alex's change here. > Or do you have some other things in mind? Alexander addressed them. main concern was postEDTTask semantics. + we have lost title => we miss part of information even in Alexander's change. > > (In reply to comment #6) > In this change semantic was really changed if compare to the original state. > > # 1 API was changed > # 2 postEDTTask is invoked in tests-mode ONLY > # 3 (even if fix this, I guess, typo) now LongWorker's doPostRunInEDT() is > started only if the doWork() was not cancelled (which was not the case before). It was the case before, see current cnd impl: if (postEDTTask != null && ! cancelled.get()) { postEDTTask.run(); } I'm fine with integrating at the beginning of nb.next
(In reply to comment #8) > Alexander addressed them. main concern was postEDTTask semantics. > + we have lost title => we miss part of information even in Alexander's change. In all usages the title is (almost) the same as message. So no information is lost... > > > > # 1 API was changed > > # 2 postEDTTask is invoked in tests-mode ONLY > > # 3 (even if fix this, I guess, typo) now LongWorker's doPostRunInEDT() is > > started only if the doWork() was not cancelled (which was not the case before). > It was the case before, see current cnd impl: > if (postEDTTask != null && ! cancelled.get()) { > postEDTTask.run(); > } > No, there is a special case (see runLongTask with LongWorker param) - it invokes finalizer in any case. > I'm fine with integrating at the beginning of nb.next
http://hg.netbeans.org/cnd-main/rev/133b376af5d9
Integrated into 'main-golden', will be available in build *201305212300* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress) Changeset: http://hg.netbeans.org/main-golden/rev/133b376af5d9 User: Andrew Krasny <akrasny@netbeans.org> Log: Bug#223810 - org.netbeans.modules.cnd.utils.ui.ModalMessageDlg.runLongTaskImpl: LowPerformance took 6612 ms.