eclipse-qvtd / org.eclipse.qvtd

Eclipse Public License 2.0
0 stars 0 forks source link

[qvti] Improve allInstances/objectsOfKind interpretation #208

Closed eclipse-qvtd-bot closed 1 week ago

eclipse-qvtd-bot commented 1 week ago

| --- | --- | | Bugzilla Link | 501650 | | Status | RESOLVED FIXED | | Importance | P3 normal | | Reported | Sep 18, 2016 05:35 EDT | | Modified | Jun 19, 2019 06:55 EDT | | See also | 547993 | | Reporter | Ed Willink |

Description

The CG execution uses an optimized EClass-based categorization into lists of input objects.

The interpreted execution uses a Pivot Class conformance based categorization into sets of input objects.

For the EXE 2016 Forward2Reverse example the input loading was about 10%, and dropped to 5% without the Sets. This should drop much further once the CG optimizations are exploited.

eclipse-qvtd-bot commented 1 week ago

By Ed Willink on Jun 19, 2019 06:55

The various loading activities for a TypedModelInstance can be merged into a single pass supervised by EClassAnalysis and EReferenceAnalysis and of course used by both interpreted and generated execution.

This revamp was performed as part of the wider revamp for Bug 547993.

The EObject to EClassAnalysis lockup is a potentially significant per-model element cost. Use of EObject.eClass() and an EClass2EClassAnalysis Map.get() is not particularly fast. For a modest number of EClasses we can have an intridice singly linked list of EClassAnalysis to support a hashed index into a small number of lists.

NB. No point using EClass.classifierId since it is lazily computed by an indexOf and we still need a 'packageId' to disambiguate.

Pushed to master for 2019-09M1