Re: [henshin-dev] Performance tweaks

[Christian Krause <henshin.ck@xxxxxxxxx>]

Hi,

here an example. In the Sierpinski-Benchmark a new RuleApplication 
object is created for every single transformation step. For level 13, 
there are 531,441 RuleApplication objects created which must be all 
garbage collected again. Just for testing, I changed the code such that 
a RuleApplication object can be reused. For level 13, the time needed 
for the rule applications decreased from 99.880s to 94.620 on my netbook 
-- so more than 5 seconds.

I am not saying that we should change the RuleApplication API, but my 
feeling is that we can improve the overall performance of the 
interpreter and the state space generator by minimizing the number of 
transient objects.

Cheers,
Christian

PS: I added shell scripts for invoking the SierpinskiBenchmark and the 
DiningPhilsBenchmark outside of Eclipse.

On 04/23/2012 12:57 PM, Christian Krause wrote:
> Hi everybody,
>
> I am currently profiling the state space generation tool and try to 
> tweak the performance as much as possible. A critical parameter for 
> the performance is the memory usage. There are two kinds of used 
> memory: (1) cached objects / models which are used to speed up the 
> look up for states, and (2) transient objects which are generated and 
> "destroyed" on the fly and used in methods to store some intermediate 
> information.
>
> I believe that (2) is a critical point for the performance of the 
> state space generation tool, and maybe also the interpreter itself. 
> The problem is that a number of objects are created, e.g. maps, lists 
> etc. which are used only once. All these objects have to be garbage 
> collected which slows down the state space generation significantly.
>
> We should be able to improve the situation by creating only transient 
> objects when it is really necessary. Instead, we should try to cache 
> as much objects as possible.
>
> I am currently caching the InterpreterEngines I use for the state 
> space generation. My feeling is that the caching inside the engine and 
> the match finder can be also improved. We should always assume that an 
> engine instance is not used concurrently. Under this premiss it should 
> be possible to cache more objects, e.g. AttributeConditionHandlers or 
> copied TransformationOptions in the engine. Storing such objects in a 
> hash map should allow us to make the memory usage more stable (less 
> transient objects). I know that the lookup in the hashmaps also takes 
> some time, but I believe that for the end performance it has a 
> positive effect.
>
> Is somebody of the interpreter developers interested in trying to 
> tweak the memory footprint for transient object / performance in this 
> direction? I really think that we can gain a speed up here.
>
> Cheers,
> Christian