Profiling your code generation

I am now developing on the Eclipse Acceleo project. To get started I bring a feature form the old Acceleo project. I write a profiler for the new Acceleo. It's very similar to the old profiler.

As you can see the screen shot show many statistics about the module execution. By double clicking on an element you can open its definition.

Thread safe services

Last month I explained how to tune Acceleo standalone engine threading. But services were still running in mutual exclusion because historically services didn't need to be thread safe. The result was a performance loss.
Services of a given service class couldn't run in parallel by default. It means threads will have to wait for other threads to run services. I noticed that a lot of service classes are thread safe, they don't use field or static references.

But as I can't decide if a service class is thread safe or not for you, I added an interface that bypass the mutual exclusion zone for a given service class. It allows multi threads to run services of a service class. This interface is IThreadSafeService. It declares nothing, so you just have to add the implements clause as following:

public MyServices implements IThreadSafeService {
...
}

But be aware, if you use this interface and your service class is not thread safe it can lead to random boggus behavior. And it can be difficult to find out what is the root cause of your troubles.

Acceleo standalone and multi-threading

One of the main features of the standalone Acceleo engine is to provide multi-thread support. This allows us to divide the code generation time according to the count of available processors, effectively cutting the generation in half on some machines. To share the work between threads, the input model is divided into groups of objects; each group is then queued till a thread can process it.

There are two parameters to tweak the multi-threaded generation. The first one is the number of threads to run simultaneously, the default value being the number of available processors plus one. This allows us to use all available processors, the one supplementary thread used to cover synchronization waiting time. While some threads are waiting for another one, one processor is free to run the thread which was waiting for an idle processor.

The second parameter is the number of objects per group, the default being 20 objects per group. This parameter is very important since its allows you to find the optimum between load sharing and thread management overhead. Your objects groups will not be processed using the same amount of time. So Imaging you divided your model into two groups by setting number of objects in the model divided by 2. The group which runs faster will have to wait for the slower group at the end of the generation. In this case you are losing time. On the oposite you can put a single object per group. This way you minimize the loss of time at the genretation end. But threads will spend more time peeking groups in the queue since there are much more groups.

To set thoses parameters have a look at :
- Extension.setThreadsNumber(int)
- Extension.setEObjectsPerThread(int)

Acceleo profiler

There is a new feature in Acceleo 2.5. This feature allows users to profile the generation process of Acceleo. To activate the profiling you should check the profiling checkbox in the launch configuration of the chain.

The result of the profiling session is saved as a model, it's very useful for performance comparison (using EMF Compare) or report creation in batch environment (using Acceleo :) ).

Basicaly the model is the execution tree of Acceleo, each node being a step of the generation process. Those nodes give statistics like the time spent in the node and its subtree, the percentage of time it represents, and the number of times the element have been run by Acceleo. You can also find the list of EObjects for each node in the outline.

The model can be sorted by chronogical order or by the time spent as shown on the screenshot. It can help in the understanding of the generation process and finding the hotspot(s). Once this hotspot is found you can open the template editor on this element by double clicking it.

I am sure this will help to optimize your Acceleo templates.

Welcome

This blog will be dedicated to my development works at Obeo. My aim is to provide useful information on products and features I am working on. This information can be technical tricks for developers or general purpose information.

Coming soon, the ability of profiling the text generation process of Acceleo...