| Performance with Stereotypes (UMLUtil.getNamedElement()) [message #1715791] |
Thu, 26 November 2015 10:12  |
 Andreas Pleuss
Messages: 18
Registered: June 2015 |
Junior Member |
|
|
I have a problem with the performance of UMLUtil.getNamedElement(ENamedElement, EObject) which is called very often when dealing with stereotyped elements. For instance, creating a large number of stereotyped elements takes very long time as many stereotype-related methods (e.g., ElementImpl.applyStereotype(Stereotype)) indirectly call UMLUtil.getNamedElement(ENamedElement, EObject).
Here is what I understand: For static profiles, getNamedElement(ENamedElement definition, EObject context) 1) first searches for the profile and 2) for the stereotype within the profile. The first step can be accelerated if the profile was registered via org.eclipse.uml2.uml.generated_package extension point, but it still takes long time if the profile cannot be not found immediately, e.g., when definition is contained in a package that is not a profile itself but is a subpackage of a profile (such as in SysML 1.4). After the profile was found, the second step still takes some time, depending on the size of the profile.
Do you have any hint how to improve performance? Have I overlooked something? If not, would it be possible to add code to UMLUtil that caches the return results of UMLUtil.getNamedElement(ENamedElement, EObject) or are there any reasons against that?
|
|
|
| Re: Performance with Stereotypes (UMLUtil.getNamedElement()) [message #1715823 is a reply to message #1715791] |
Thu, 26 November 2015 13:02  |
|
Hi,
Would you mind raising a bug in Bugzilla? I would not expect there to
be much reason against introduction of a performance cache for
scenarios like this. If you can provide a sample that demonstrates the
problem, that would be great, and a proposed patch would be even better!
Some kind of time- or size-bounded cache of these named-element
look-ups, probably within the CacheAdapter, would seem reasonable. The
primary concern, as always with the CacheAdapter, is ensuring that such
cache doesn't cause memory leaks when models reachable from it are
unloaded and no longer in use.
Cheers,
Christian
On 2015-11-26 10:12:05 +0000, Andreas Pleuss said:
> I have a problem with the performance of
> UMLUtil.getNamedElement(ENamedElement, EObject) which is called very
> often when dealing with stereotyped elements. For instance, creating a
> large number of stereotyped elements takes very long time as many
> stereotype-related methods (e.g.,
> ElementImpl.applyStereotype(Stereotype)) indirectly call
> UMLUtil.getNamedElement(ENamedElement, EObject).
> Here is what I understand: For static profiles,
> getNamedElement(ENamedElement definition, EObject context) 1) first
> searches for the profile and 2) for the stereotype within the profile.
> The first step can be accelerated if the profile was registered via
> org.eclipse.uml2.uml.generated_package extension point, but it still
> takes long time if the profile cannot be not found immediately, e.g.,
> when definition is contained in a package that is not a profile itself
> but is a subpackage of a profile (such as in SysML 1.4). After the
> profile was found, the second step still takes some time, depending on
> the size of the profile.
> Do you have any hint how to improve performance? Have I overlooked
> something? If not, would it be possible to add code to UMLUtil that
> caches the return results of UMLUtil.getNamedElement(ENamedElement,
> EObject) or are there any reasons against that?
|
|
|
|
Powered by
FUDForum. Page generated in 0.03313 seconds
] 
Search
Help
Register
Login
Home
