Using Local Variables in Non-Screen-Refresh Procedures

[Geotale]

While a bit strange, and while it doesn't affect everything, this seems to end up being faster for the most mundane of tests I've performed.
Some example code I've tested goes as follows:

const b0 = stage.variables["i7e1+r]oi.vDL+g,MgiU"];
const b1 = stage.variables["3.1NP3ZpuHl$`ogFNl.c"];
const b2 = target.variables["*{W${3-ca}UZFVGd|.PH"];
return function fun2_test () {
for (var a0 = 100000000; a0 >= 0.5; a0--) {
b0.value = randomFloat(-100000, 100000);
b1.value = randomFloat(-100000, 100000);
b2.value = (b0.value / b1.value);
}

being transformed into

return function fun2_test () {
var b0 = stage.variables["i7e1+r]oi.vDL+g,MgiU"].value;
var b1 = stage.variables["3.1NP3ZpuHl$`ogFNl.c"].value;
var b2 = target.variables["*{W${3-ca}UZFVGd|.PH"].value;
for (var a0 = 100000000; a0 >= 0.5; a0--) {
b0 = randomFloat(-100000, 100000);
b1 = randomFloat(-100000, 100000);
b2 = (b0 / b1);
}
stage.variables["i7e1+r]oi.vDL+g,MgiU"].value = b0;
stage.variables["3.1NP3ZpuHl$`ogFNl.c"].value = b1;
target.variables["*{W${3-ca}UZFVGd|.PH"].value = b2;

This cuts my time running this from 7.87 seconds to 6.89 -- Not the largest cut, 14% faster, but it's still a noticeable cut for a simple function where the most amount of time is generating random numbers, and it's consistently at least faster for any loop I tested that runs for a nonzero amount of time -- Of course, nonzero meaning, this is probably slower if a procedure doesn't use loops.

One other thing to (optionally, but probably) do is be to find what total variables any given procedure uses, specifically what that procedure itself calls (terminating the optimization if there's any recursion with the initial procedure), and optimize out any variables that aren't ever part of said list -- Attempting to optimize them out in these cases, with reading and setting before and after each function call respectively, turns out slower from my tests, meaning the current method is simply favorable when a called function uses said variables. Either way, this should be possible in a far more vast amount of projects and general scripts, and should handle the issue with function calls in general, even more so if you only take into consideration function calls used outside of loops, which adds extra setting (and possibly resetting) but likely would still end up faster thanks to only occurring once, compared to a previous loop which uses these variables multiple times -- This scenario of a loop before a function call outside of the loop is likely a bit obscure, but it's still probably out there in a few projects.
This detection also helps with issue 36, when Warp Timer is disabled, as you don't have to forget any variable types that aren't going to be modified by function calls, which applies even when a procedure doesn't have loops (and therefore the other optimizations here don't apply).

Finally, this could be done with Warp Timer enabled, if you set all variables to their current local values before each yield, and as previously mentioned, forget variable types after each call and at the beginning of each loop (which is to be expected anyways) -- As JavaScript runs many, many loops before said yields, it should always still be far faster to do this with Warp Timer enabled than not to.

[GarboMuffin]

It would probably be even faster to do

var c0 = stage.variables["i7e1+r]oi.vDL+g,MgiU"];
var c1 = stage.variables["3.1NP3ZpuHl$`ogFNl.c"];
var c2 = target.variables["*{W${3-ca}UZFVGd|.PH"];
return function fun2_test () {
var b0 = c0.value;
var b1 = c1.value;
var b2 = c2.value;
for (var a0 = 100000000; a0 >= 0.5; a0--) {
b0 = randomFloat(-100000, 100000);
b1 = randomFloat(-100000, 100000);
b2 = (b0 / b1);
}
c0.value = b0;
c1.value = b1;
c2.value = b2;
}

It won't make a difference in this microbenchmark but in real projects it might