Epsilon is a family of Java-based scripting languages for automating common model-based software engineering tasks, such as code generation, model-to-model transformation and model validation, that work out of the box with EMF (including Xtext and Sirius), UML (including Cameo/MagicDraw), Simulink, XML and other types of models.
I am using an ECL script as part of the reference implementation for a TTC 2023 case.
I have noticed two things:
Before I moved away from using compare to decide if there was a match (using a guard) instead, ECL was storing all matches (whether passing or failing) in its trace. This was significantly slowing it down as it uses the getMatch method to find if a match was already computed or not, and for a model with 50 containers I was getting 61k matches in total. This may be intended ECL behaviour, but it's an easy trap to fall into: in the end, I left compare as just true and used the guard for the actual check.
While looking at getMatch, I notice that it loops over all matches, repeatedly testing if the match is for those two exact objects (Match#contains compares object identities directly). It'd be much faster to use two levels of IdentityHashMaps for this.
I am using an ECL script as part of the reference implementation for a TTC 2023 case.
I have noticed two things:
compareto decide if there was a match (using aguard) instead, ECL was storing all matches (whether passing or failing) in its trace. This was significantly slowing it down as it uses thegetMatchmethod to find if a match was already computed or not, and for a model with 50 containers I was getting 61k matches in total. This may be intended ECL behaviour, but it's an easy trap to fall into: in the end, I leftcompareas justtrueand used the guard for the actual check.getMatch, I notice that it loops over all matches, repeatedly testing if the match is for those two exact objects (Match#containscompares object identities directly). It'd be much faster to use two levels ofIdentityHashMaps for this.