[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [mdt-ocl.dev] Benchmark results OCL/Ecore Plugin Tests
|
Ed,
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.
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.
Best,
-- Axel
On 3/14/2011 3:22 PM, Willink, Ed wrote:
Hi Axel
I feel that you're flogging the wrong horse.
1) We can try to accelerate execution by using switch(...) based on
Ecore feature IDs instead of polymorphic visitor dispatching
and see how
much that gains.
The pivot evaluator apart from dynamic dispatch does direct dispatch via
OperationCallExp to the OperationCallExp.referredOperation
to Operation.implementation which is a Java class; no visits, no switches.
The Pivot variant of LoopExp has an equivalent referredIteration so no
need to string match a set of reserved iterator names.
2) We can try to improve specific bottlenecks such as the
tuple hash
code computation (easily solvable by caching the constant
tuple's hash
code once computed), as well as the tuple creation process
which seems
to spend more time than seems appropriate for cloningi an
IntegerRange
which, as an immutable object itself, could just be
referenced instead
of copied in this case.
Already cached in the Pivot variant; it gave me a lot of debugging trouble
because Tuple hashes were not repeatable for compatible types such as 4 and
4.0.
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
_______________________________________________
mdt-ocl.dev mailing list
mdt-ocl.dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/mdt-ocl.dev
