Skip to content
Kensuke Sawada edited this page Jan 30, 2016 · 4 revisions

Emfrp Performance

Emfrp has a potential to achieve the performance which bears comparison with the native C program by simple optimizing. However, current Emfrp compiler doesn't do such optimizing. In this section, I discuss the performance of the ideally optimized Emfrp program.

About Memory (Space-complexity)

Evaluated node-values

One evaluated node-value must be held while it is used for other nodes to evaluate. Then, the needed amount of memory for the whole program is determined by the max number of nodes required at the same time during the whole runtime-process.

Note that entities of Emfrp's objects excluding instances of primitive types such as Int and Double are allocated on Global Allocation Area mentioned later. Then, node-values are just pointers to their entities in Global Allocation Area.

Data values

Values defined by the data statement are hold forever. Their entities are also allocated on Global Allocation Area.

Global Allocation Area (GAA)

Entities of Emfrp's objects are allocated here. The decision of one object's life and death is done by the algorithm similar to Mark and Sweep GC algorithm. The necessary size of GAA can be statically decided by program's lexical tokens. A summary of how to decide the size of GAA is shown in here.

About Speed (Time-complexity)

Evaluating expressions

The only expression Emfrp has and C doesn't have is using local variables as an expression. This gap can be solved by compiling to C's if-statement without any overheads.

Instantiating data-types

This costs the additional time relative to size of GAA by one cycle of evaluating all nodes. Here, size is not byte-size but number of data. It is about 10 to 100 for practical applications. This may be ignorable.

Runtime-process (evaluating nodes)

This costs the time relative to the number of nodes. There are no unignorable overheads.

Clone this wiki locally