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.
Automated performance tests shows too long time to create class diagram from multiple selection. See results in millisec : http://test4u.czech.sun.com/test4u-users/nb-perfteam/results/20070626152140/spb-perf-xp2/testrun_070626-173548/testbag_23/user/gui.actions.CreateClassDiagramFromMultipleNodes/Create%20Class%20Diagram%20From%20Multiple%20Nodes/Create%20Class%20Diagram%20From%20Multiple%20Nodes.log
See URL field for latest results, time is above 15 seconds.
The majority of the analysis and fixes in this issue is applicable to IZ 108269 and IZ 112211 as well. The following baseline measurements were obtained on my notebook (Windows XP, jdk 1.5.0_10, Centrino Duo 2.33, 2G RAM) For each operation there are 3 measurements - 1st creation of the diagram, 2nd and 3rd in a row. IZ 108267, ie. this issue (CLD_2_ELEMS) : 5.5 (another run 6.5 was observed), 2.2, 2.1 seconds IZ 108269 (SQD_2_ELEMS) : 5.7, 2.5, 2.3 IZ 112211 (DEP_JEDIT) : 10.1, 6.3, 6.4 After some inefficiencies were found and corrected the measurements are: IZ 108267 (CLD_2_ELEMS) : 4.8 (2.0 CL), 1.8, 1.5, another run: 3.5 (0.8 CL), 1.6, 1.5 IZ 108269 (SQD_2_ELEMS) : 4.1 (0.7 CL), 2.0, 1.8 another run 5.0 (1.9 CL), 1.8, 1.9 IZ 112211 (DEP_JEDIT) : 6.5 (0.9 CL), 4.3, 4.0 Observation 1. The time of the first invocation significantly floats. The reason for that is the corresponding floating of the class loading time during the operation. This time is listed as ( <number> CL) in the table above, and it floated in the experiments from 0.7s to 2.0s. The first invocation causes about 1.9 (with 0.8 CL) to 3.1 (with 1.9 CL) "penalty" vs. subsequent invocation. The non-classloading part of the "penalty" in various cases was about 1.1 to 1.4s. All the noticeable (ie. taking 0.1s or more) components of the non-classloading part of the penalty were identified as following: (the times listed below are in addition to the classloading performed during these operations) 0.2 - "decrypting" of the TomSawer library 0.2 - TomSawer initialization 0.15 - palette loading and creation 0.3 - XSLT factory creation and template compilation, 0.5 in case of SQD_2_ELEMS These components are pretty much irreducible (except possibly palette creation, yet the expected gain there even in the best case wouldn't significantly affect the results). Thus the first time invocation in cases of CLD_2_ELEMS and SQD_2_ELEMS needs to be adjusted to be at least 2.5 times of the time of subsequent invocation to accomodate the "first time invocation penalty", that in CLD_2_ELEMS and SQD_2_ELEMS cases may be up to 1.5 times of the time of subsequent invocation. The specific value in seconds need to be explicitly calibrated on the recommended configuration machine. Observation 2. With the mentioned above fixes the subsequent invocation times in cases CLD_2_ELEMS and SQD_2_ELEMS is 1.5 - 2.0s. The 0.5s component of that time is taken by actually saving of the diagram using XMLWriter from dom4j and thus pretty much beyond UML plugin control (redevelopment using other libaries, etc. even if it would bring improvement is beyond the scope of these bugfixes) The remaining part 1 - 1.5s was looked into and no other significant improvements other than the above mentioned fixes were found. Observation 3. In the case of IZ 112211 (DEP_JEDIT) the resulting dependency diagram for jEdit class is a class diagram containing 21 elements - 11 classes and interfaces and 10 datatypes (datatypes doesn't contain attributes and operations and thus noticeably "cheaper" to format onto a diagram). The time to generate this diagram shouldn't be expected to significantly differ from the time to create a class diagram with the same set of elements. For simplicity i used the 15 classes Shift-selected from jEdit up to BeanShell under the same package (org.gjt.sp.jedit) (CLD_15_ELEMS) Additionally there were also measured 2 cases: - (DEP_ABBREVS) generation of dependency diagram for the first node in the package: org.gjt.sp.jedit.Abbrevs The class diagram with 5 datatypes and 3 classes (Abbrevs, Abbrevs.Expansion, View) is generated here. - CLD_3_ELEMS - class diagram for 3 classes (Abbrevs, Abbrevs.Expansion, View) from DEP_ABBREVS The measurements are: (copied from the table above) DEP_JEDIT : 6.5 (0.9 CL), 4.3, 4.0 CLD_15_ELEMS : 6.6 (1.0 CL), 4.2, 4.0 DEP_ABBREVS : 4.0 (0.7 CL), 2.0, 1.9 CLD_3_ELEMS : 4.2 (0.8 CL), 2.0, 2.0 The difference between larger cases (DEP_JEDIT and CLD_15_ELEMS) and smaller (DEP_ABBREVS and CLD_3_ELEMS) is about 2s. The major part of this 2s difference is about 0.9 additional time taken by saving of the bigger diagram (i.e. ~1.4s vs. ~0.5s) using external XML library, ie. not controlled by UML plugin. The remaining part, ~1.2s, was looked into, and it presents a somewhat linear growth related to the number of elements (and their subelements, like attributes/operations) to be added and formatted onto the diagram. Thus the target time for generate dependency diagram should be adjusted to be about the same as the time taken by the creation of a class diagram containing the same set of elements (or similar). Changesets: changeset: 75257:e8e3244f6948 user: lvv@netbeans.org date: Tue Mar 25 03:02:15 2008 -0800 summary: Partial fixes for 108267 Time to create class diagram exceeds thres hold changeset: 75258:38883101fd99 tag: tip user: lvv@netbeans.org date: Tue Mar 25 03:07:56 2008 -0800 summary: Partial fixes for 108267 Time to create class diagram exceeds thres hold changeset dc3523ea4b14 in main details: http://hg.netbeans.org/main?cmd=changeset;node=dc3523ea4b14 description: Partial fixes for 108267 Time to create class diagram exceeds threshold and changeset de2744035d09 in uml-meteora details: http://hg.netbeans.org/uml-meteora?cmd=changeset;node=de2744035d09 description: Partial fixes for 108267 Time to create class diagram exceeds threshold changeset db2545d06f8d in uml-meteora details: http://hg.netbeans.org/uml-meteora?cmd=changeset;node=db2545d06f8d description: Partial fixes for 108267 Time to create class diagram exceeds threshold
After reading through Viktor's comment and observations, I now understand that the time for creating dependency diagram should be about the same as the time needed to create class and sequence diagram. So, I agree with Viktor that the target time for creating dependency diagram should be adjusted. I'll make the adjustment in the performance scenario table. This means the overall improvement looks good in this fix.
verified in NB 6.1 latest continuous trunk build 1340 (20080327130455). verified with jEdit project for creating class and sequence diagrams from 30 selected classes, and one of the class there for dependency diagram. All creation were timed less than 5 seconds on inital creation.
Tests still report that 5 sec threshold is not enough for recommended platform. See issue 133098.