The balance between framed executables and native code

The balance between framed executables and native code

There is a requirement to find the balance between executable elements wrapped in frames, and native code. The ratio depends on your needs, how much memory you are ready to spend for internal frames storage, and what computing power you can leave for the system dynamics and ease of generic interface between frame structures including a user interface.

In a real aplications, there are a large number of external libraries and framework, which sometimes can be quite large in terms of API complexity (LLVM, Spring, Kaffka, etc). It is not suitable to wrap these libraries into framed API even in case of use languages with rich reflection such as Python and JS. These libraries can be shadowed, without making them available in frame graphs, you can wrap them manually call by call.

Writing automated import generators for libraries requires a big work on making a large set of mapping between types, used for library calls, and frame system.

The more frame-bound features you use in runtime, the more computing power and RAM is spent on EDS interpretation. Until this losses affordable for you, it is better to stay high-level be able to do tooling, automated transformations and interactive debug. When you arise your efficiency limits, its time to rethink the system design, and carry out most loading code to low level.

To illustrate it, let's review the case of using EDS for science computations or compilers design. Until your working data sets stay small and processing speed not too low for you, it is good to compute symbolically, having some features like precision analytic computations, tolerance analysis, and debugging. As an example, we can run some sort of calculator able to do analytic integration, simplification and plotting.

While your requirement rises, and system answer slower and slower, we must reject usability by moving to source code generation and use of lightweight optimizing compilers. This compiler can be external and work in batch mode, like calling GNU g++ from your system. Or, as a variant, you can implement your own specialized compiler by using LLVM or JIT library in runtime.

Managed compilation