Direct reporting of the IDE slowness

New feature pointing to lazy parts of the IDE was just implemented in dev builds of 6.8. System slowness detected message is shown to the user and the user is asked to report such problems into Issuezilla manually. The idea of this project is to interconnect the functionality with exception autoreporting tool and provide a way of direct problem reporting to a server, possible duplicates and severity analysis and correct component/subcomponent issue filling.


  • The system slowness is detected
  • A notification is shown with the information
  • If the slowness is really huge (for example > 5s in AWT thread), the report link will be shown additionally in the notification window
  • Just one click allow user to submit the problem in a simillar way as the exception reporting works
  • UI actions, messages.log and profiler nps data will be collected and submitted to
  • Based on profiler nps file possible duplicates analysis and component/subcomponent guess will be done using tools used for exceptions reporter
  • In case of more duplicates an issue will be filled directly containg all accessible information in the same manner as ReporterProcessFlow


  • Easier and faster interaction with the comunity and possibility to inform user about already reported or alredy fixed performance problems
  • Bigger feedback on performace from more users
  • Possible statistics about the slowness tracking
  • Duplicates and component/subcomponent automatization
  • The possibility to filter not serious performance problems and really serious problems
  • The possibility to enhance UI logging or messages.log logging to get more informations about the involved HW, SW, platform etc.
  • Registered users or GUEST submits

Duplicates detection

There are various ways to analyse the slowness report and group them using their similarities.

Latest invoked action

UI Logger is able to review UI actions as menu, shortcuts, toolbar or editor actions so we can mark duplicates based on latest invoked action. The problem is that threre are many other UI actions we are not able to track easily. As an example let's say an event of mouse click on user component in Navigator view or Drag&Drop from palette. In such case the latest UI action as menu or toolbar invokation is already old and gives no sence and it's needed to use different way.

The actual behavior is that if there was an action invoked less than one second before the UI freeze, the action is marked as cause of the problem and all reports caused by this action are marked as duplicates.

NPS snapshot

While the UI is frozen, NetBeans start to profile it self and it caches a NPS snapshost. Based on this snapshot we can see what was happening in the AWT thread during the freeze. The question is how to find the root cause of the problem. The basic idea is to find a suspicous method that is causing the biggest slowness. The algorithm pseudo-code follows:

actualMethod = getAWTRootMethod();
while (actualMethod != null){
  if (actualMethod.selfTime > 20% of actualMethod.totalTime){
      return actualMethod; // suspicious since it takes a lot of time itself
  if (there is just one method called by the actualMethod){
     actualMethod = actualMethod.child;
  if (there are more then one method called by the actualMethod){
     if (there is a child taking more than 80% of parents total time){
         actualMethod = majorChild of all childer;
         return actualMethod; // suspicious since there is no major child and the performance problem starts to granulate


AWT Thread Blocked

AWT Thread is blocked on well-known lock and it waits for another thread In this case a suspiscious method is found, but is just a victim of another slow thread that should be fast by definition, but it's not.

See this example: In the following image you can see piece of AWT thread where openide.nodes calls getNodes() method that should be as fast as possible, but it has blocked for long time. The problem is obviously in different thread - not the AWT thread. Fortunatelly we know, that the slow code will be called from Children.callAddNotify() method.



The second image shows Request processor thread containg Children.callAddNotify() that has caused the slowness. You can see that the deffender is RestServiceNodeFactory.

There are probably many similar cases to this one, the only thing is to find the incorrectly marked suspicious method, the root of the slow code that we should look for and let us know.

The duplicates algorithm

    1. find all issues caused by the same action
    2. find all issues caused by the same suspicous method
    3. is there some report in the intersection? -> mark as duplicate of the latest issue in of the intersecion
    4. there are no issues caused by the same action -> mark as duplicate of the latest issue having the same suspicous method
    5. nothing passes -> mark as a new report

Other accessible informations for each submit from a user

  • Messages.log
  • Profiler nps snapshot
  • UI logger of latest 1000 actions
  • Latest invoked action
  • Slowness length
  • AWT Thread snapshot in direct view
  • User machine memory size
  • User machine CPU count
  • OS
  • JDK
  • NetBeans version
  • Duplicates


  • Extends the slowness notification UI .......... DONE
  • Adapt the functionality of exception reporter to submit performance data .......... DONE
  • Server performance data acceptation .......... DONE
  • Server performance data analysis ............ DONE
  • Addapt UI to show all data correctly ........ DONE
  • Set criteria for serious problems -> should be filled in IZ and not serious problems -> should be stored only in the server DB .... DONE - Nearly the same criteria as for exception reports are used. The only difference is that no direct users are defined for slowness reports and very slow reports (over 20s) are reported directly instead.
Not logged in. Log in, Register

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