MethodScript

MethodScript has the ability to apply different optimization techniques, both at compile time and runtime. Due to the architecture of the engine, it is fairly straightforward to tag functions with various optimizations. === CONSTANT_OFFLINE === If all the parameters of a function are constant, a function with this optimization will be run at compile time, and that value stored, instead of it being run each time. For instance, the add function is like this, which means that if you were to do add(2, 2), it would simply replace that call with 4, at compile time, which makes it more efficient during runtime. Since 3.3.1 === INSTANT_RETURN === Some functions can be run async, and there is no benefit for it to wait around for the operation to finish. For instance, using sys_out() does not need to wait for the IO to flush before returning control to the script. Since 3.3.1 === OPTIMIZE_CONSTANT === A function may be able to do some optimization if the parameters are constant, but it may be a bit more complicated than simply running the function. Otherwise, this is exactly like CONSTANT_OFFLINE Since 3.3.1 === OPTIMIZE_DYNAMIC === Some functions can do some amount of optimization or compilation checks, even if the function is sent dynamic parameters. For instance, if(true, rand(), '1') can be changed simply to rand(), because the condition is hard coded to be true. In this case, the compile tree is smaller, which makes it more efficient. Since 3.3.1 === CACHE_RETURN === If a function is able to optimize out constant inputs, it can likely also cache the return value. If the engine determines that it is faster to cache the returned values vs re-running the function, it may choose to do so. This is a runtime optimization, and is calculated by the engine itself to determine which method is faster, so there is no guarantee that any optimization will occur, however, unless this option is specified, it will certainly not. Since 3.3.1 === TERMINAL === If a function is "terminal", that is, it is guaranteed to have abnormal code flow (for instance, return() or throw()) it is marked terminal, which is used by the compiler to issue warnings, in the event you make some code unreachable by putting it under a terminal statement, and to optimize by removing the unreachable code from the code tree. Since 3.3.1 === NO_SIDE_EFFECTS === If a function is "side effect free", that is, if the return value is unused, the function itself does nothing, then this optimization can be specified. This is mostly useful for cases where the value returns a check, but the check has been determined by the compiler to be unused, making the entire call itself unneeded, allowing the call itself to be removed from the tree. Since 3.3.1 === CUSTOM_LINK === Some functions do want to do linking, but in a special, custom way. If this is specified, then the function will have the link() method called on it, in place of the default linking mechanism that the compiler provides. Since 3.3.1 === PRIORITY_OPTIMIZATION === This is a priority optimization function, meaning it needs to be optimized before its children are. This is required when optimization of the children could cause different internal behavior, for instance if this function is expecting the presence of some code element, but the child gets optimized out, this would cause an error, even though the user did in fact provide code in that section. Since 3.3.1

Find a bug in this page? Edit this page yourself, then submit a pull request.