Bug 223810 - org.netbeans.modules.cnd.utils.ui.ModalMessageDlg.runLongTaskImpl: LowPerformance took 6612 ms.
org.netbeans.modules.cnd.utils.ui.ModalMessageDlg.runLongTaskImpl: LowPerform...
Status: RESOLVED FIXED
Product: cnd
Classification: Unclassified
Component: -- Other --
7.3
All All
: P4 (vote)
: 7.4
Assigned To: Andrew Krasny
issues@cnd
EXCEPTIONS_REPORT perf-profileme
: PERFORMANCE
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2012-12-13 22:08 UTC by szmitek
Modified: 2013-05-22 02:36 UTC (History)
1 user (show)

See Also:
Issue Type: DEFECT
:


Attachments
nps snapshot (48.98 KB, application/nps)
2012-12-13 22:08 UTC, szmitek
Details
Proposed patch (32.27 KB, patch)
2012-12-19 21:01 UTC, Andrew Krasny
Details | Diff
Fixed patch (52.57 KB, patch)
2012-12-20 10:26 UTC, Alexander Simon
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description szmitek 2012-12-13 22:08:52 UTC
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
Comment 1 szmitek 2012-12-13 22:08:54 UTC
Created attachment 129350 [details]
nps snapshot
Comment 2 Andrew Krasny 2012-12-19 11:21:20 UTC
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?
Comment 3 Andrew Krasny 2012-12-19 21:01:15 UTC
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.
Comment 4 Andrew Krasny 2012-12-19 21:03:02 UTC
Alex, Vladimir, 
I would like to get your comments... 

Thanks,
=Andrew
Comment 5 Vladimir Voskresensky 2012-12-20 09:36:52 UTC
semantic was changed, does not look safe to integrate now
Comment 6 Alexander Simon 2012-12-20 10:26:14 UTC
Created attachment 129576 [details]
Fixed patch
Comment 7 Andrew Krasny 2012-12-21 09:30:41 UTC
(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
Comment 8 Vladimir Voskresensky 2012-12-21 09:50:59 UTC
(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
Comment 9 Andrew Krasny 2012-12-21 09:56:01 UTC
(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
Comment 10 Andrew Krasny 2013-05-21 10:42:23 UTC
http://hg.netbeans.org/cnd-main/rev/133b376af5d9
Comment 11 Quality Engineering 2013-05-22 02:36:47 UTC
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.


By use of this website, you agree to the NetBeans Policies and Terms of Use. © 2014, Oracle Corporation and/or its affiliates. Sponsored by Oracle logo