# Additional Notes

### Limitations

The incremental generation process can only be used with EMF-based models. That's because all intermediate artifacts ( diff model and trace model ) which reference the original models are also stored as EMF models. It is therefore not possible to refer to other model formats. Moreover, you should make sure that your model has stable IDs for the individual model elements so that the model comparison doesn't run into any ambiguities.

Also note that at the moment, Xpand cannot track access to model elements from JAVA extensions. This can lead to cases where a change in a specific model element should trigger a specific (set of) file(s) to be regenerated, but it actually doesn't. That's because Xpand didn't know about the model element being accessed during the original file generation, so it has no indication that a regeneration is required. For that reason you should try to access your model as much as possible from Xpand or Xtend, and only resort to JAVA code when it is unavoidable.

### Performance Considerations

The main performance benefits of incremental generation come from not doing things that are not necessary. Given the workflow from the section called “The Incremental Generation Callback”, it may seem counterproductive to first perform a costly model comparison operation before it can even be determined whether a file has to be generated or not.

While it is true that model comparison is a very expensive operation, it turns out that it still outweighs the costs of unnecessarily generating files, even if no postprocessing or subsequent compiler invocation is involved.

That said, it is definitely preferrable to do without a model comparison and rather capture the changes to the model on-the-fly. So whenever you are working in a controlled environment, you may want to consider a customized integration of the generator invocation with the model editors.