Create optimization module

[atsepkov]

Similar to linter, there are a number of benefits to creating a separate optimizer module. Some of the benefits include:

• moving out existing output.pyj conditionals like range(len(n)) replacement with a simple for loop into optimizer (and test for range(n.length) and other formats)
• replacing long if/elif chains with switches
• unrolling 1-liner functions
• replacing constant variables with their values in code
• remove unused/dead code
• unrolling static arrays ([1 til 10] -> [1,2,3,4,5,6,7,8,9])
• compile-time computation of static variables: ""a " + "b" -> "a b", 2**16 -> 65536
• removal of unneeded optionals (if nothing calls a function without the optional argument, remove the one-liner it uses)

Additionally having an optimizer would allow us to make the language behave more like python without inheriting the performance cost. For example, a quick test I did showed that wrapping equality operator in a single function call makes the operation about 120 times slower. This is bad news for making equality work properly with arrays (or add any sort of operators overloading). However, if an optimizer could track variable type and "unroll" the function call to the operation as needed, this would make the overhead much less brutal. For example:

def func(b):
    a = 5
    if b == a: # last local assignment to a is a number, it's safe to assume native equality will suffice
        ...

The point is, inbuilt optimizer, aware of the language syntax, can do much better than an external one assuming that the code is pure JavaScript.

[atsepkov]

Hmm, I don't want to favor a particular engine/compiler since I see that falling in "premature optimization" category - even if V8 is most-used. There are, however, obvious optimizations that an intelligent JavaScript developer will make and RapydScript may not be able to due to syntax difference. These are the kinds of optimizations of I want to concentrate on. Things like unrolling a loop with static variables (no doubt [1,2,3,4,5,6,7,8,9,10] will be faster than range(1,11), for example). Interesting article, however. Luckily it doesn't seem like RapydScript is at risk of being affected by those since strict mode already prevents many of those hacks and infinite loops are a user creation.