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.

Bug 111962 - RE big project to the same UML project gets stuck at 25% progress
Summary: RE big project to the same UML project gets stuck at 25% progress
Status: VERIFIED FIXED
Alias: None
Product: uml
Classification: Unclassified
Component: Reverse Engineering (show other bugs)
Version: 6.x
Hardware: PC Windows XP
: P2 blocker (vote)
Assignee: Viktor Lapitski
URL:
Keywords: PERFORMANCE
Depends on:
Blocks: 123522
  Show dependency tree
 
Reported: 2007-08-03 23:02 UTC by Sherry Zhou
Modified: 2008-03-27 00:59 UTC (History)
1 user (show)

See Also:
Issue Type: DEFECT
Exception Reporter:


Attachments
Ctr-Break thread dump (45.68 KB, application/octet-stream)
2007-09-11 21:23 UTC, Craig Conover
Details
Blueprint source files (NB project not included) (250.67 KB, application/octet-stream)
2007-09-12 21:54 UTC, Craig Conover
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Sherry Zhou 2007-08-03 23:02:21 UTC
build 070803

Attempt to RE JEdit project.
It has no problem to RE first time. But RE never complete at second time - wait for 10 minutes and abort.

Here is the steps
 0. Set netbeans momery usage to -Xmx1024
 1. Open JEdit project and Reverse the whole project. It takes about 2 minutes (until the progress bar disappears)
 2. Reverse whole project to the same UML model, the progress bar stops at 25%, step 2 of 4. Output 
    shows Analyzing attributes & operations for 656 symbols. RE never complete.
Comment 1 Petr Nejedly 2007-08-08 08:19:28 UTC
Please attach few thread dumps sometimes later in the neverending RE.
Comment 2 Viktor Lapitski 2007-08-08 11:35:30 UTC
>Please attach few thread dumps sometimes later in the neverending RE.

for UML development there isn't need for any additional info in case 
of this issue as the problem is well reproducible, and the report was 
filed on request of the development after it was reproduced 
and source of the problem analized
Comment 3 Craig Conover 2007-09-11 21:23:44 UTC
Created attachment 48605 [details]
Ctr-Break thread dump
Comment 4 Craig Conover 2007-09-11 21:59:38 UTC
Made summary more concise.
Comment 5 Craig Conover 2007-09-12 21:48:40 UTC
Using a slightly less complex/large Java project (Blueprints sources - attached to this issue), it does take awhile, but
does eventually complete. It looks as if the larger jEdit sources are taking longer due to the obvious... it just has
more elements to process hence, more memory usage, as well.
Comment 6 Craig Conover 2007-09-12 21:54:21 UTC
Created attachment 48686 [details]
Blueprint source files (NB project not included)
Comment 7 Craig Conover 2007-09-12 22:03:25 UTC
The bottleneck caused by the selection of xml nodes from DOM. Specifically this method call in XMLManip class:
  public static List selectNodeList(org.dom4j.Node pNode, String pattern)
which calls:
  list = pNode.selectNodes(pattern); // pNode is a dom4j.Node as the param above declares

All this originates from the UMLParsingIntegrator class in the method:
  public boolean handleVersionedElement(
    Element docElement,Node childInDestinationNamespace,Node elementBeingInjected,String finalXMIID)
when it calls UMLXMLManip.replaceReferences(docElement, xmiIDToChange, href), which eventually calls the selectNodeList
method above.

Each element can take from 5 to 10 or more seconds and the memory consumption slowly increases. With thousands of
elements, this takes too long and if the memory is set too low for the VM, it will eventually OOME I would assume
(haven't proven that, but seems likely).

Improving the node selection process should remedy the performance issue. Perhaps indexing can be performed?
Comment 8 Craig Conover 2007-09-13 02:27:34 UTC
I increased my mx mem setting to 1024 (probably didn't need to be that high) and the process did eventually finish... in
117 minutes. So it's a matter of time and bit of memory. The JVM actually peaked at about 380 MB when the process was
finished.

The performance issue is as stated before... XML node query selection for every single element in the project. Solutions
are being looked into.
Comment 9 Craig Conover 2007-09-13 02:30:28 UTC
Workaround:
It is not likely that after RE'ing a large Java project that you would want to continually RE the entire project again.
More likely, you will make some changes to the some sources and RE just a portion of the project (likely, only the
changed source files). If it is necessary to RE the entire project, it might be better to RE it into a new UML project,
if that is indeed an option.

A true performance solution, if one exists, is still the end goal.
Comment 10 George Vasick 2007-09-21 20:12:30 UTC
We do not have infrastructure in place to search the existing model when re-reverse engineering into the same model. 
The search is linear, the time required is n*n.

The work around is to delete the model and recreate or selectively RE only the required source files.  If he RE must
really be performed on the entire project, it will finish if the user waits long enough.
Comment 11 George Vasick 2007-12-18 18:48:55 UTC
Using jEdit41 project:


Initial reverse engineering into a new UML project:

Begin processing Reverse Engineering
Parsing 320 elements
Analyzing attributes & operations for 505 symbols
Resolving 468 attribute types
Integrating 505 elements
Building the query cache.
================================
Task Successful (total time: 22 seconds)


Second reverse engineering operation into the same UML project:

Begin processing Reverse Engineering
Parsing 320 elements
Analyzing attributes & operations for 505 symbols
Resolving 468 attribute types
Integrating 505 elements
Building the query cache.
================================
Task Successful (total time: 13 minutes 38 seconds)
Comment 12 Viktor Lapitski 2008-03-14 23:37:58 UTC
now RE of jEdit  into the same existing project takes close to the 
first RE - something about 50 sec. whereis first time was about 40 sec. 

changeset:   73601:eee115a8f8cf
user:        lvv@netbeans.org
date:        Fri Mar 14 15:29:36 2008 -0800
summary:     Fix for 111962 RE big project to the same UML project gets stuck at
 25% progress

changeset:   73602:7212a55f8903
tag:         tip
user:        lvv@netbeans.org
date:        Fri Mar 14 15:34:04 2008 -0800
summary:     Fix for 111962 RE big project to the same UML project gets stuck at
 25% progress

and

changeset:   71093:dd511810d282
user:        lvv@netbeans.org
date:        Fri Mar 14 02:42:22 2008 -0800
summary:     Fix for 111962 RE big project to the same UML project gets stuck at
 25% progress

changeset:   71094:c3a2421b43fe
tag:         tip
user:        lvv@netbeans.org
date:        Fri Mar 14 02:43:36 2008 -0800
summary:     Fix for 111962 RE big project to the same UML project gets stuck at
 25% progress



 
Comment 13 Peter Lam 2008-03-27 00:59:34 UTC
verified in NB 6.1 build 200803251204.

Here are the results for reverse engineering jEdit. In the 2nd & 3rd runs, there's a couple of seconds in delay to
confirm a popup informational dialog.

**** 1st RE of jEdit 

Begin processing Reverse Engineering


Parsing 320 elements

Analyzing attributes & operations for 585 symbols

Resolving 488 attribute types

Integrating 585 elements

Building the query cache.

================================
Task Successful (total time: 59 seconds)


**** 2nd RE of jEdit to the same model

Begin processing Reverse Engineering


Parsing 320 elements

Analyzing attributes & operations for 585 symbols

Resolving 488 attribute types

Integrating 585 elements

Building the query cache.

================================
Task Successful (total time: 1 minutes 2 seconds)


**** 3rd RE of jEdit to the same model

Begin processing Reverse Engineering


Parsing 320 elements

Analyzing attributes & operations for 585 symbols

Resolving 488 attribute types

Integrating 585 elements

Building the query cache.

================================
Task Successful (total time: 1 minutes 2 seconds)



Here's the result for reverse engineering org.netbeans.modules.uml.core module. There were a few informational dialogs
needed to be confirmed.

**** 1st RE of org.netbeans.modules.uml.core module

Begin processing Reverse Engineering


Parsing 1,441 elements

Analyzing attributes & operations for 1,482 symbols

Resolving 1,020 attribute types

Integrating 1,482 elements

Building the query cache.

================================
Task Successful (total time: 3 minutes 56 seconds)


Begin processing Reverse Engineering


Parsing 1,441 elements

Analyzing attributes & operations for 1,482 symbols

Resolving 1,020 attribute types

Integrating 1,482 elements

Building the query cache.

================================
Task Successful (total time: 4 minutes 21 seconds)