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.
nbusers posting from ggreenberg@responsys.com: I am still fiddling with UML module. I installed latest daily (200710160000) and decided to reverse engineer couple of existing projects. First I tried a small one with less then 100 classes and it did it in about 6 minutes. However, I expected to see class association diagram at the end, but NB did not produce one. I hoped to use it for documenting the project. If I have to create a diagram myself after that, I don’t see much of a value in the reverse engineering. Then I decided to try a big project (class library), some classes of which I wanted to use as an import into the new UML project. Pretty quickly progress bar climbed to 50% and then stuck. For next 2 hours it grew to 52%. Task manager showed CPU utilization fluctuating from 50 to 100% on my dual core 1.86GHz CPU with 3.5GB of RAM. I left it running overnight and cancelled it this morning at 63% completion. Here is the log of reverse engineering: Begin processing Reverse Engineering Parsing 2,057 elements Analyzing attributes & operations for 2,816 symbols Resolving 1,796 attribute types Integrating 2,816 elements ================================ Task Cancelled (total time: 1254 minutes 53 seconds) Cancelled Building the query cache. ================================ Task Cancelled (total time: 1255 minutes 31 seconds) I, then tried to do the same thing with the evaluation copy of Visual Paradigm and it completed reversing that project in 26 minutes but hung on building the diagram and was killed after 2 hours. Sybase PowerDesigner successfully finished reverse engineering and building class diagram for the very same project in less then 18 minutes. PowerDesigner is a windows .exe file, so, higher performance is understandable, but not to the 2 orders of magnitude. I’d love to hear some comments on presented facts.
Comments from Viktor: After updating of the build i see the problem - the time, really long one, is spent in new method Project.getElementImports() which overrides the Package.getElementImports(). Technically the difference is in XQuery: //UML:Package.elementImport/* vs. UML:Package.elementImport/* While at brief look it seems logical and correct here, performance-wise the "//" query is a real killer inside huge XMLs like UML Core, and looks like now it is executed for each attempt to resolve an attribute or a parameter type (ie. number of times something on the scale of tens of thousand ). (the same also applicable for "//UML:Package.packageImport/*" inside Project.getPackageImports() )
Project.getElementImports() is frequently accessed, the raw xpath query is time consuming, add cache mechanism to boost performance.
verified in trunk build 20071023180752 (b4116). For uml core (2634 classes, 2830 elements (1896 attribute types) consisting of attributes & operations, it's now taking 19 minutes, 23 seconds to complete reverse engineering on the following system. This is slightly better than the time (21 minutes, 1 second) it took to do the same in a previous build (20071002223241) before the regression. Windows XP SP2 Pentium 4 CPU 2.66 GHz 1 GB of RAM