| Re: [mdt-papyrus.dev] [Performance] Css/stereotypes element creation |
|
Hi, I found the class that is refreshing all the diagram [1] (There is a TODO suggesting to refresh only a part of the diagram) ð
I removed this method and didn’t see obvious regressions. What is the catch? I also found a class that seems to call refresh on label too many times [2] ð
Is there a reason for calling the refresh label many times ? (In a Requirement creation, it will call refresh label 3 times for each property) Regards, Benoit 1: org.eclipse.papyrus.infra.gmfdiag.css.engine.ExtendedCSSEngineImpl
/** *
{@inheritDoc} * * Handles a notification that an Element has changed.
* * Source: GMFElementAdapter */
@Override
public
void notifyChange(Element
elementAdapter) {
resetCache();
//
TODO: We should only refresh a subset of the cache
//
FIXME: It seems the refresh can create a deadlock in some cases
Diagram
diagram =
Set<?
extends DiagramEditPart>
diagramEditParts = PapyrusDiagramEditPart.getDiagramEditPartsFor(diagram);
if (!diagramEditParts.isEmpty())
{
//
TODO: Contextual refresh more specific than the diagram?
for (DiagramEditPart
next :
diagramEditParts) { DiagramHelper.scheduleRefresh(next); } }
else { DiagramHelper.scheduleRefresh(); } } 2: org.eclipse.papyrus.uml.diagram.stereotype.edition.editpart.AppliedStereotypeMultilinePropertyEditPart L820
protected
void handleNotificationEvent(Notification
event) {
refreshLabel(); Object
feature =
event.getFeature();
if (NotationPackage.eINSTANCE.getFontStyle_FontColor().equals(feature))
{ Integer
c = (Integer)
event.getNewValue(); setFontColor(DiagramColorRegistry.getInstance().getColor(c)); }
else
if (NotationPackage.eINSTANCE.getFontStyle_Underline().equals(feature))
{ refreshUnderline(); }
else
if (NotationPackage.eINSTANCE.getFontStyle_StrikeThrough().equals(feature))
{ refreshStrikeThrough(); }
else
if (NotationPackage.eINSTANCE.getFontStyle_FontHeight().equals(feature)
|| NotationPackage.eINSTANCE.getFontStyle_FontName().equals(feature)
|| NotationPackage.eINSTANCE.getFontStyle_Bold().equals(feature) || NotationPackage.eINSTANCE.getFontStyle_Italic().equals(feature))
{ refreshFont(); }
else {
if (getParser() !=
null && getParser().isAffectingEvent(event,
getParserOptions().intValue())) {
refreshLabel(); }
if (getParser()
instanceof
ISemanticParser) {
ISemanticParser
modelParser = (ISemanticParser) getParser();
if (modelParser.areSemanticElementsAffected(null,
event)) { removeSemanticListeners();
if (resolveSemanticElement() !=
null) { addSemanticListeners(); }
refreshLabel(); } } }
super.handleNotificationEvent(event); } De : mdt-papyrus.dev-bounces@xxxxxxxxxxx [mailto:mdt-papyrus.dev-bounces@xxxxxxxxxxx]
De la part de MAGGI Benoit Hi everyone, I’m having some performance issues in SysML 1.4. The basic use case is creating some SysML 1.4 stereotypes elements. I used jvm monitor [1] to make a sample analyze [4] It seems that most of the time is lost in StereotypeDisplayUtil [2] (either it’s called to often, either there is something wrong inside) I looked in the code, and know I have some questions:
-
A diagram seems to be refreshed for each element creation. Is it expected (“normal”)? (seems a lot of useless refresh in most use cases)
-
Is there tests for StereotypeDisplayUtil? (I didn’t find a StereotypeDisplayUtilTest class)
-
A stereotype Compartment seems to be linked to stereotype. Why isn’t it directly linked to a stereotype application?
-
The monitor report didn’t show any sysml14 classes in the
Hot spots. But I may probably have a bad configuration in SysML 1.4, any ideas/suggestions?
-
Is there a recommended way to add performance tests/benchmark in Papyrus? (for example using [3]) Regards, Benoit 2 : org.eclipse.papyrus.uml.diagram.common.stereotype.display.helper.StereotypeDisplayUtil 3 :http://openjdk.java.net/projects/code-tools/jmh/ 4 :
|
