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: | Performnace: Navigation Editor is painfully slow and messy while working with large project | ||
---|---|---|---|
Product: | obsolete | Reporter: | Winston Prakash <wjprakash> |
Component: | visualweb | Assignee: | Joelle Lam <joellelam> |
Status: | RESOLVED FIXED | ||
Severity: | blocker | CC: | issues, j_lau, sandipchitale |
Priority: | P1 | ||
Version: | 6.x | ||
Hardware: | All | ||
OS: | All | ||
Issue Type: | DEFECT | Exception Reporter: | |
Attachments: |
Performance Test Project
Regular Performance Testing Project |
Description
Winston Prakash
2007-07-01 22:26:08 UTC
Created attachment 44609 [details]
Performance Test Project
I will take a look at this issue. From first glance, it's hard to know if it is one single thing that is causing this. But when nodes are expanded, this is triggering insync to draw all the pages. Does the tigger team have any metrics on how long it takes for insync to model all the pages so I can determine if that is the primary factor of this delay? One way to test this would possibly be to do as Winston suggested and keep the nodes unexpanded, but I need to confirm that my code does not actually load the model regardless. I think we should simply look at the performance hotspots using a profiling tool (such as NetBeans profile or JProfiler) to see what is going on. Yes, we should do some profiling and find the exact hots pots. If I guess correctly, most of the time taken while opening Navigation Editor is due to insync modeling the pages. Navigation Editor should avoid using API like getDesignContexts() (IMO, this is one of the worst API introduced, a top notch performance killer. We must put our foot down and return not support message if this API is called). The clients of this API must look at other ways to work this around. Navigation editor could work this around like this. When the project is opened do not open the nodes at all. When user request for a node opening get the context using the API findContext(name) and get the DesignBean of type ActionSource. We need to run the profiler to find other performance issues such as performance during drag and connect etc. I made most of the necessary change to only upload the page content items upon request, however, it seems that the graph library does not have an API for me to listen to the expansion action. In the past I just added the pins and the GraphLibrary did the reset when it came to zoom. I can request that David add this API, but I need to know for sure this is something we want to do. There were complaints originally from QE that because the nodes where not zoomed, they did not look like they had sub components. Since performance is a P1, does this trump the usability request? Created attachment 44644 [details]
Regular Performance Testing Project
Tiger Team, Can you use this newly attached project to narrow down some of the problem. Obviously it is faster because there is no insync modeling, however it is still slow. Insync calls are now made on a background process. However, this does not seems to be the primary source of the issue. It seems that the more links and pages there are, the longer it takes for the graph library to lay it out. I am working with David Kaspar to see if he has any recommendations. IDE:------------------------------------------------- IDE: [7/11/07 3:17 PM] Committing 2 Projects started Checking in web/jsf/navigation/src/org/netbeans/modules/web/jsf/navigation/graph/PageFlowScene.java; /cvs/web/jsf/navigation/src/org/netbeans/modules/web/jsf/navigation/graph/PageFlowScene.java,v <-- PageFlowScene.java new revision: 1.92; previous revision: 1.91 done Checking in visualweb/navigation/src/org/netbeans/modules/visualweb/navigation/VWPContentModelProvider.java; /cvs/visualweb/navigation/src/org/netbeans/modules/visualweb/navigation/VWPContentModelProvider.java,v <-- VWPContentModelProvider.java new revision: 1.12; previous revision: 1.11 done Checking in web/jsf/navigation/src/org/netbeans/modules/web/jsf/navigation/JSFPageFlowMultiviewDescriptor.java; /cvs/web/jsf/navigation/src/org/netbeans/modules/web/jsf/navigation/JSFPageFlowMultiviewDescriptor.java,v <-- JSFPageFlowMultiviewDescriptor.java new revision: 1.27; previous revision: 1.26 done Checking in web/jsf/navigation/src/org/netbeans/modules/web/jsf/navigation/Page.java; /cvs/web/jsf/navigation/src/org/netbeans/modules/web/jsf/navigation/Page.java,v <-- Page.java new revision: 1.22; previous revision: 1.21 done Checking in web/jsf/navigation/src/org/netbeans/modules/web/jsf/navigation/PageFlowView.java; /cvs/web/jsf/navigation/src/org/netbeans/modules/web/jsf/navigation/PageFlowView.java,v <-- PageFlowView.java new revision: 1.98; previous revision: 1.97 done Checking in web/jsf/navigation/src/org/netbeans/modules/web/jsf/navigation/Bundle.properties; /cvs/web/jsf/navigation/src/org/netbeans/modules/web/jsf/navigation/Bundle.properties,v <-- Bundle.properties new revision: 1.14; previous revision: 1.13 done Checking in web/jsf/navigation/src/org/netbeans/modules/web/jsf/navigation/PageFlowController.java; /cvs/web/jsf/navigation/src/org/netbeans/modules/web/jsf/navigation/PageFlowController.java,v <-- PageFlowController.java new revision: 1.106; previous revision: 1.105 done IDE: [7/11/07 3:18 PM] Committing 2 Projects finished Okay, I have a conflict of interest with this bug. After talking with David it seems that I will have to use a different router to represent a case (or link). However, that means that edges will actually cross through nodes and links like before. Winston, will this be an acceptable fix for you? In otherwords, the "messy" requirement of this bug will now become worse. Here are David's Comments: ----------------------------------------------------------------------- The issue is in the OrthogonalSearchRouter. It has very slow computation (~ exponential time complexity) for path routing. This router is suitable up-to 20 nodes and 20 edges on a screen :-(. Unfortunately I do not have any other implementation of a router. The only solution is: 1) to use DirectRouter which creates straight lines or 2) Limit a number of objects in the CollisionCollector that is passed as an argument to the OrthogonalSearchRouter. 2a) Edges are really evil since they are treat as a multiple-regions objects. Therefore you can try to use node Widgets only in the CollisionCollector. Then the path may be sometimes overlapping but the routing will many times faster. 2b) Use a WidgetsCollisionCollector which will be resolving collision-regions this way: only a source node and target node widgets will be taken as collisions. Then the algorithm should be very fast and should handle hundreds nodes. 3) to create a new Router implementation which creates orthogonal paths but does not avoid nodes and or other edges. A similar algorithm was created in GraphLibrary 1.0 as SimpleLinkRouter class. Regards, David This bug is still being worked on. Unfortunately, orthogonal router used by graph library seems to work best with no more than 20 nodes and 20 links. The work around would be to modify the edge router once the faces-config exceeds a certain number of cases. However, this does not fix the "messy" issue as stated earlier. I also plan to pursue additional routing algorithms, but I am expecting that there will be insufficient time to put this into place. Put a generic fix in that basically sets any edge to direct if there are more than 20 edges already. |