Enhancement
Critical
Major
Detail
Detail
The TL model is being used more and more frequently. As a result, it is becoming increasingly apparent that this can lead to performance problems. Especially when the type hierarchy is required, this is a problem: In such cases, the entire hierarchy is recursively searched upwards or downwards with each call, whereby even duplicate paths are not recognized as such but are traversed multiple times.
Improvement
Especially methods like TLModelUtil.isCompatibleInstance(...) and getConcreteSpecializations should use a cache as well as avoid unnecessary overhead from the start due to for example duplicate paths in the model. The other methods in tl:TLModelUtil should also be checked for their optimization potential.
Application
The cache has been built into tl:TLModelUtil and is used automatically. If you still want to call this cache directly, you can do it like this: {{#!java TLModelCacheService.get().getSubClasses(TLClass) }}}
The cache has been built in so that these calls will work even if the cache is turned off. Then the result is recalculated for each call as before.
Result
This made the tests from the demo in the nightly build about 10% faster: 33 minutes instead of 36 minutes.
Code Migration
- ReplaceTLModelUtil.calcAllSuperClasses(TLClass) and TLClass.getAllSuperClasses() ` with `TLModelUtil.getReflexiveTransitiveGeneralizations(TLClass).
- MetaElementUtil.getAllSubMetaElements(TLClass) replace with `TLModelUtil.getTransitiveSpecializations(TLClass).
- ReplaceMetaElementUtil.getConcreteTransitiveSpecializations(TLClass) with TLModelUtil.getConcreteSpecializations(TLClass).
- ReplaceMetaElementUtil.getSuperMetaElements(TLClass) with TLClass.getGeneralizations().
- TLModelUtil.getSubMetaElements(TLClass) replace with TLClass.getSpecializations().
- TLModelUtil.calcAllParts(TLClass) replace with TLClass.getAllClassParts().
- TLModelUtil.getAllGlobalClasses(TLModel) returns a set instead of a list.
- The following methods now return immutable collections as they directly return values from the cache:
- TLModelUtil.getMetaAttributes(TLClass)
- TLStructuredType.getAllParts()
- TLClass.getAllClassParts()
Test
TestTLModelUtilPersistent has been extended with appropriate tests. The transient tl:TLModel does not test the cache because it is active only for the persistent tl:TLModel. The correctness of the calculated values in the cache is already checked by the normal tests of the persistent TLModel. Therefore, the new tests only check the caching itself: is the same object really returned for each call? And are the values returned by the cache unmodifiable?