Re: [mdt-ocl.dev] Benchmark results OCL/Ecore Plugin Tests

["Willink, Ed" <Ed.Willink@xxxxxxxxxxxxxxx>]

Hi Axel 

> with "polymorphic visitor dispatching" I was not primarily 
> referring to 
> how OperationCallExp expressions are evaluated but rather to 
> the general 
> evaluator's design which is based on the visitor pattern. This uses 
> polymorphic calls to accept(Visitor) which in turn call the specific 
> visit...Exp operation on the visitor. It should be possible 
> to replace 
> this visitor pattern by a simple switch statement in 
> AbstractEvaluationVisitor.visitExpression which then 
> immediately calls 
> the specific visit...Exp method. You mentioned that the Dresden 
> implementation does a similar thing and, if I understood you 
> correctly, 
> surmised that this was a key reason for their better 
> performance. If I 
> misunderstood then never mind.

Yes, you misunderstood the polarity.

Dresden OCL is (perhaps was) 4 times _slower_, because they used EcoreSwitch
which invokes caseXXX at every level of inheritance. The one level Visitor
is much quicker. A straight switch would be quicker still but inextensible
and unable to share cases by inheritance. With auto-generation of the
dispatcher this might not be an issue.

> Good if the Pivot evaluator can already correctly cache Tuple 
> hashCodes. 
> The challenge in hashCode caching should, however, not be affected by 
> the other challenge of correctly defining what the hashCode 
> has to be. 
> The issue you mention (4.0 being equal to 4) is hopefully correctly 
> implemented already in the current Tuple's hashCode 
> implementation and 
> would therefore not be affected by the caching.
> 
> I was only offering to provide a patch that does this caching of an 
> already correct value. Again, if you have good indication that the 
> profile I presented earlier is not representative (which is very well 
> possible, of course), then I can save the effort.

The old code can obviously be improved and in so far as it helps old code
users then it is helpful. However if we are to move on with finite
resources, it may be more profitable to enhance the new code.

I regard the new evaluator as definitely better with potential for
a fair number of improvements and then optiomisation via direct partial
or total code generation.

I regard the new Xtext parser/analyzer as useful but in need of considerable
further work/automation.

An old to new AST tranmsformation might be helpful, possibly as an extension
of
the existing handcoded Ecore2Pivot.

	Regards

		Ed

Please consider the environment before printing a hard copy of this 
e-mail. 
 
The information contained in this e-mail is confidential. It is intended 
only for the stated addressee(s) and access to it by any other person is 
unauthorised. If you are not an addressee, you must not disclose, copy, 
circulate or in any other way use or rely on the information contained in 
this e-mail. Such unauthorised use may be unlawful. If you have received 
this e-mail in error, please inform us immediately on +44 (0)118 986 8601 
and delete it and all copies from your system. 
 
Thales Research and Technology (UK) Limited. A company registered in 
England and Wales. Registered Office: 2 Dashwood Lang Road, The Bourne 
Business Park, Addlestone, Weybridge, Surrey KT15 2NX. Registered Number: 
774298 
 
Thales UK Limited. A company registered in England and Wales. Registered 
Office: 2 Dashwood Lang Road, The Bourne Business Park, Addlestone, 
Weybridge, Surrey KT15 2NX. Registered Number: 868273