# Incremental Generation

As projects become larger, so typically do their models. However, the larger the models are, the longer the code generation process takes. In a mature project, a developer typically changes only a small part of a large model. Performing a full code generation process for the whole model slows down the development cycle considerably due to various factors:

- The whole model must be traversed, and each statement in the Xpand templates must be executed. The larger the model is and the more Xpand templates you have, the higher the negative impact is.
- All generated files are written to disk. The I/O operation itself is one major contributor to the overall elapsed time. What's more, files are typically post-processed by beautifiers, which is another time consuming operation. If you are working with protected regions, the impact is even more dramatic.
- Since every file has a new timestamp after code generation, typically a compiler will pick up these new files and start compilation, which adds more CPU and I/O cycles to the process.

Considering that for a small change in the model only a fraction of the generated files actually do change their contents, performing a full generation is obviously a waste of time.

Beginning with the Helios release train (Eclipse 3.6, Xpand 0.8), Xpand now ships with an incremental generation facility. This works very similar to the incremental Java compiler in Eclipse. It detects which parts of a model have changed since the last generation process. It then determines which files need to be generated due to that change and which are unaffected by it. Only the former are the regenerated, while the latter remain untouched.

The following sections explain how this incremental generation feature works and how you can use it.

## Technical Background

The key to incremental generation lies in knowing which element in a model was used to generate which file. This information can easily be computed during generation, by tracking which parts of the model are accessed in the context of any given `«FILE»` statement. A callback for the Xpand generator does this job and builds up a so-called trace model on-the-fly.

The second important information is the actual change that has occurred in a model. There are basically two ways to compute this. One is to attach a change listener when editing the model and capture the change as it happens. The other way is to keep a backup copy of the model and compare the old version with the current version to compute the change. See the section called “Performance Considerations” for pros and cons of each of the two ways. In either case, the result is a so-called diff model .

When we know which parts of a model have changed, and we also know which files have been produced based upon these parts of the model, we can then skip the generation of all other files, thus performing incremental generation.