| Re: [henshin-dev] Performance tweaks |
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
Attachment:
signature.asc
Description: OpenPGP digital signature