Skip to content
This repository has been archived by the owner on Feb 12, 2022. It is now read-only.

Optimized function

Dominic Gannaway edited this page Jun 12, 2018 · 3 revisions

The standard way to use Prepack is the execute the global code of a set of files and then to write out a target file whose global code is the result of synthesizing a new program that faithfully recreates the same final heap as the final heap of the original code, but hopefully doing it much more efficiently. Any function that is reachable from the final heap is regarded as a call back and its code is left largely unmodified in the target program. The call backs are invoked by the environment after the global code has finished running.

In some cases, the environment may want to do further initialization of the global heap after doing some user interaction that does not alter the heap resulting from the original global code. This makes sense if the further initialization is expensive and is not required in every execution of the prepacked code.

Such initialization code could also benefit from being prepacked and hence there is an option to specify additional functions to optimize along with the global code. Such functions have to be independent of each other. This means that one optimized function may not read a value that is written by another optimized function. In other words, the order in which these functions are called should not matter. Assuming this is true, Prepack can use the heap values that resulted from running the global code, as if they were constants.

In order for Prepack to optimize a specific function, you need to tell Prepack the function you want to optimize. This can be done via a special internal function __optimize(fn) where fn is a reference to the function you want Prepack to try and optimize. For example:

function myFunction() {
  return 2 + 2;
}

// use this function to tell Prepack
// to optimize "myFunction" above
__optimize(myFunction);

When using optimized functions, Prepack makes the assumption that the function is in "pure scope". Visit the compiler assumptions pages for more details on these assumptions.

Note: it is also a conflict if one function overwrites the values written by another function (except, of course, if both functions write exactly the same value and neither reads the value).