Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [mdt-ocl.dev] Benchmarks

Hi Axel

An interesting start.

I think we want to keep analysis/parser completely separate from evaluation,
since for some users only evaluation matters, and for others analysis/parser
is all
that matters.

> Other than that we see two 
> noticeable 
> bumps in self-time:
>   - OperationCallExpImpl.accept (line 390, the 
> visitOperationCallExp call)
>   - VariableExpImpl.accept (line 250)
> This to me suggests that Ed is pointing in a useful direction when it 
> comes to comparing the execution time performance of switching by 
> numeric Ecore feature IDs versus employing double-dispatch to visit 
> polymorphically.

I may have imporved VariableExp too. Currently there is a by name search of
the environment with a fair amount of too-ing and fro-ing re/deconstructing
strings
and a lot of environment poking.

The pivot code looks up by VariableDeclaration avoiding name occlusion
issues.
The pivot evaluator also exploits mutable environment content, so when an
iteration
changes its accumulator, it uses a derived e.g. OrderedSet$Accumulator that
supports
a mutable add, safe in the knowledge that the Accumulator as an iteration
private
variable that any consumers must copy. There's a FIXME in the code to
support
mutable IteratorValues too.

In general, the pivot evaluator pursues the policy that all analysis is done
at compile
time; for instance implicit set is resolved by insertion of an
OclAny.oclAsSet() call
in the AST. Operation dispatch is the only dynamic behavior need run-time
decisions.

The above considerations suggest that we should separate collection/scalar
behavior too;
scalar behaviour will depend on control infrastructure, while collections
are amenable to
fast support.
> 
> I'll try to get another benchmark run that is not primarily 
> focused on 
> IA aspects but has more plain OCL evaluation to do. Let's see 
> what I can 
> find. A good start may be the existing OCL/Ecore plugin tests.

I doubt it. There is very little that is volume execution. Just tons of tiny
compiles and evaluates.

	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 


Back to the top