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.