| Re: [henshin-dev] Performance tweaks |
|
Hi, I was not able to reproduce the effect on a machine with more memory (8GB). It is not really easy to get consistent data for the benchmarks. Sometimes the measured times vary a lot and it is not always possible to say what caused the difference or whether a change in the implementation improves the performance under different conditions. Still, I think that we should try to improve the memory consumption, especially for short-living objects. I believe that we cannot only handle larger models / transformations, but also improve the performance with this. For instance, the Match class could be implemented more efficiently. Instead of keeping 3 separate HashMaps, the Match class could directly extend LinkedHashMap and store all data directly in this map. Cheers, Christian On 24.04.2012 09:09, Stefan Jurack wrote: Did you created a branch with that changes? This would surely help others to reproduce your results. Am 23.04.2012 21:19, schrieb Christian Krause: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_______________________________________________ henshin-dev mailing list henshin-dev@xxxxxxxxxxx https://dev.eclipse.org/mailman/listinfo/henshin-dev |