pvginkel
commented
11 years ago This can still be improved. Currently we bail out when:
- If a get member/index is done. Ideally we only make the variable a JsInstance when a set member/index is done. If only get member/indexes are done, these can be replaced by calls on the prototype directly;
- If we have a read before write. This can be fixed by e.g. making the types nullable. Then, when the type is null, we return undefined.
Besides that, only double types are currently being created. This can be optimized to also create int types if we can prove that the variable is only treated as an integer.
Currently, all values are still JsInstance values. This should be changed to native .NET values where possible.
There are two levels to this. Firstly, all variables (locals and lifted) should be typed object and start out as their native values. This means that e.g. a double becomes a boxed double. When an operation is performed on the variable that requires it to become a JsInstance (e.g. a property is set), the boxed double is silently converted to a JsInstance. This means that all operations that could have this effect on a variable should get ref references to the storage location.
The second level is more interesting and is where the real performance gains are. We could do a usage analysis on variables. When we can prove that no operations can be performed on the variable that would require it to become a JsInstance, and the variable keeps it original type all the way through its lifetime, the type of the variable could be its real native type. We may have to add some special support for its initial value, because all variables start out as undefined. This could be solved by making the variables Nullable<> and returning JsUndefined.Instance when the variable hasn't been assigned yet. This could also be optimized away when the variable is definitely assigned.
One thing that should be taken into account is that not all member operations require it to become a JsInstance. E.g. when we execute a method on a variable, this should still work on native variables. Normally, we would get the prototype of the JsInstance to find out how to resolve the method. When the variable is (still) a native value, we could hard code the prototype lookup and resolve members that way.
Where this gets more complicated is when variables are assigned to. If a variable is assigned a new time, and it's not lifted, we may create a new variable for this. The idea here is that when we can prove that the original value of the variable isn't read after the point it's assigned a value of a new type, we can just create a new variable for it (e.g. i`1) and give that a new type.
One thing to also take into account is that it may be a good idea to also allow int as a type for local variables, specifically for these circumstances. One of the major gains you'll see here is for optimizing a "for (var i = 0; i < arr.length; i++)", and that specifically is an int.