Papyrus/Oxygen Work Description/Refactoring/PerformancesImprovements

Thanks to their experience in modeling performance and their expertise on the VIATRA technology, IncQuery Labs contributes to the Oxygen release of Papyrus by:

• Providing means to assess and monitor some performance critical use cases in Papyrus.
• Improving the performances on some of these cases.

Use cases:

1. Open a model (with many diagram already opened)
2. Navigation in model explorer (Especially with stereotype with custom icons)
3. Drop an element from the palette (Especially with a custom css)
4. Drop an element from the model explorer (Especially with a custom css)
5. Change the selection with the property view open
6. Flat View in Select type widget
   • Create a model with many elements
   • Create a class with a property
   • Select the property and set the type in the property view
   • In the popup widget there is a tab named Flat (this tab presents all elements from the model and can be slow in big models)
7. Create View dialog (Flat tab is no longer displayed in this case!)
   • Open a model with many model elements
   • In the Welcome page of the Papyrus editor, click on the Create View button
   • In case of large models, simply opening the dialog takes minutes or even more
8. Filter in Model explorer
   • Open a model with many model elements
   • In the model explorer use the search/filter box
   • In case of large models, the model tree takes some times to refresh

Tasks:

Task 1.

Setting up a continuous scalability evaluation testbed for Papyrus. This testbed will be based on RcpTT tests and Hudson jobs

Its goal is to:

1. highlight future regressions
2. validate future enhancements

Further details

Task 2.

Identifying and sharing existing models (UML, notation, css, profile) related to performance bottlenecks in Papyrus. The Papyrus community is expected to share some models, but many performance issues are only present in big proprietary models (Obfuscation will probably be required)

Its goal is to:

1. share a library of models that can be used for any kind of testing in Papyrus

Further details

Task 3.

Integrate a Papyrus specific indexing module based on the VIATRA base-indexer and query engine to improve model navigation and derived feature usage. Based on the 2 previous tasks, there will be an evaluation before and after the model integration to check performance improvements.

Further details

Links

To be completed:

• links to shared models
  • Obfuscated SysML 1.4 model on git
• links to RcpTT tests and Hudson performance jobs
  • RCPTT project on git
  • Hudson job for running RCPTT performance test suite on SysML 1.4 product: https://hudson.eclipse.org/papyrus/view/Sysml/job/papyrus-sysml-oxygen/

User interface performance evaluation

The use cases listed above (1-6 at the moment) are each measured by RCPTT testcases that are added to the SysML 1.4 Git repository as the input model used is SysML 1.4. The testcases reuse the already existing common RCPTT contexts from the Papyrus Tools and SysML 1.4 RCPTT projects.

The performance measurement is using the start-measure and stop-measure ECL commands, with the output written to log files in the workspace.

let [val uri "workspace:/logs/case1-open-diagrams.log"] {
  // Empty file (if exists)
  write-lines -uri $uri
 
  start-time-measure "Open Model"
  open-file -project $projectName -file $modelName
  stop-time-measure "Open Model" | write-lines -uri $uri -append
}

In the most basic case, the above example measures the time it takes Papyrus to open an existing model.

proc "measure-property-view-selection" [val tree -input] [val element] [val message] [val uri] {
  try -command {
    with [$tree | get-item $element] {
      start-time-measure $message
      select-item
    }
  } -finally {stop-time-measure $message | write-lines -uri $uri -append}
}

Note that since RCPTT commands are rather slow, we try to minimize the amount of RCPTT commands inside the measurement window. In the example above, we make sure RCPTT finds the item in the tree before we make the selection itself.

The results of the testcases are written to log files that look like the following in the end (duration in milliseconds):

org.eclipse.rcptt.ecl.perf.impl.PerfCounterImpl@22eee37e (name: Open Model, duration: 13588)
org.eclipse.rcptt.ecl.perf.impl.PerfCounterImpl@57cf0bbb (name: Basic navigation, duration: 19521)
org.eclipse.rcptt.ecl.perf.impl.PerfCounterImpl@21531395 (name: Open Diagram, duration: 8679)
org.eclipse.rcptt.ecl.perf.impl.PerfCounterImpl@b9da5a6 (name: Navigate to, duration: 1746)

Shared model library

In order to provide a truly reusable shared model library, there should be a single entry point for all information on the models, this is probably a Wiki page with a link to the repository location of the model library.

The following is an incomplete, draft list of information that could be useful in a model library:

• Model library level information:
  • List of models
  • General description on library structure (how to use the models)
  • Guide on adding new models
  • Guide for using models without copy-pasting
    • update site / feature, Maven repository and group:artifact identifiers
    • Java code for accessing models from tests
    • RCPTT context with procedures for adding the project to the workspace
• Model level information:
  • Unique identifier to be used for referencing the model from list of models, issues or documentation
  • Model files
  • Short description
  • Usage guide (profiles/features needed)
  • Model metrics (number of elements, references, etc.)
  • Copyright information (who contributed it)

Papyrus specific indexing module

Following a detailed performance analysis of the cases 1-7, a few code segments were identified where performance issues were caused by repeated access of the model, more specifically repeated calculation of applied profiles and stereotypes. Even through this was only one of the causes of the slowdowns, a generic indexer feature is introduced to address such issues relying on the Indexer component of VIATRA.

The Gerrit changes https://git.eclipse.org/r/#/c/85788/ and https://git.eclipse.org/r/#/c/86487/ provide a prototype implementation for this feature: the first one introduces a Papyrus service to initialize the indexer and make it available for use, while the second updates UMLProfileHelper implementation to use this service.

The proposed functionality is as follows:

• The freshly introduced service UMLModelIndexingService starts as an UML service, and it initializes the base indexer, and provides UML-specific APIs over the top of it.
• The single specific ProfileApplicationIndexer provides a lazy cache implementation: when asked, it calculates the profile applications, and stores it in a map; and listens to base index changes to invalidate cache entries on model changes.
• The service is added as an EMF Adapter to the model to support accessing it from model processing code.

Remaining tasks:

• Measure the effects of this change using the use cases.
• Check whether this indexing service can be reused in other cases as well.