Optimization route

I've recently added two new entries to the Code Generation Optimization Ideas page. As one can see there are many things that can improve the performance of the generated code. Even when a back-end C compiler runs with complete set of optimization options, it cannot figure out the semantics of the code behind (at least not at the time of writing). Probably there are some research projects that do much deeper analysis, but let's focus on the real life examples.

As soon as we talk about memory layout, object structure or dynamic dispatch tables, it becomes difficult (for the back end translators) to see what can be precomputed and reused without the need to compute it all the time and what is dynamic and can change over time. If you have a closer look at the page above, you'll note that all the optimizations rely on the properties of the Eiffel execution model:

1. Objects cannot change their type. As soon as the type of the object is known, it can be used to compute whatever we need - offsets of attribute fields, addresses of associated features, types of parents, etc. All of these can be calculated once and then used without the need to do it again and again. Even moving GC does not affect this type-specific information.
2. If an entity is attached to a particular object and is not reattached before use, any type-specific information can be safely reused without recomputation.

This observation does not depend on whether the code is generated in open (workbench) or closed (finalized) mode. In other words, such optimizations can be perfomed all the time. Yet they are not planned for the near future. But since the source code is open, you can make it rolling now, just drop us a line.