| Re: [henshin-dev] Performance tweaks |
|
No. I changed the following things: - added "isExecuted = false" to RuleApplication.setMatch() - changed SierpinskiBenchmark from for (Match match : matches) { addTriangle = new RuleApplication(engine, addTriangleRule); addTriangle.setMatch(match); addTriangle.apply(); } to addTriangle = new RuleApplication(engine, addTriangleRule); for (Match match : matches) { addTriangle.setMatch(match); addTriangle.apply(); } The effect is visible when a large number of transformations are executed over a longer time period, e.g. in the benchmark for level 13 or higher, or when generating large state spaces. If you run a benchmark, make sure that Java has the same amount of memory available (the relevant options are set automatically in the script) and that you choose a case that takes at least 1-2 minutes. I also expect that the performance gain will be greater when more objects a re-used, e.g. model changes, match objects or similar. In the state space generator, the overuse of the garbage collector is also apparent when you activate the memory usage widget in the bottom of the workbench. At some point, the memory usage jumps up and down within a few seconds or even hundreds of milliseconds. In each of these jumps, the JVM is busy with garbage collecting. There is a German article that explains how garbage collecting works in general: http://www.angelikalanger.com/Articles/EffectiveJava/26.GarbageCollection/26.GarbageCollection.html I believe that during long transformation sequences as in the benchmark or in the state space generator, there is a large number of short living objects and that the JVM is busy sweeping these objects. This theory is also supported by an experiment I did for the state space generator: I increased the amount of cached state models for the state space generation. One would think that since more objects are stored and don't need to be derived on-the-fly, the performance would increase. The opposite happened. My explanation is that since more memory is used for the cached models, less memory is available for the short living objects (lists, iterators, RuleApplications(!)) and more time is necessary for the garbage collecting. 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 |