Well I would not recommend writing code like mr. C to anyone. Unless you really-really-really need every last usec you can get :-)
The goal was just to show that sometimes JS code generated by some tool sometimes can be faster than handwritten JS code just because it tries to emulate something foreign (like low-level memory semantics) and thus reducing certain overheads. So one should be very careful when extrapolating speed shown by some project into effectiveness of the whole language.
[also I tried to stress the fact that speed is not everything there is to performance. If you have a long lived webapp in your tab you suddenly might become concerned by memory usage. Which is rather difficult to predict partially because of the "hairy" nature of the heap, the fact that VM tries to adapt to your app but doesn't always get it right, and the cost of the VM itself (e.g. generated code and additional data structures)]
The goal was just to show that sometimes JS code generated by some tool sometimes can be faster than handwritten JS code just because it tries to emulate something foreign (like low-level memory semantics) and thus reducing certain overheads. So one should be very careful when extrapolating speed shown by some project into effectiveness of the whole language.
[also I tried to stress the fact that speed is not everything there is to performance. If you have a long lived webapp in your tab you suddenly might become concerned by memory usage. Which is rather difficult to predict partially because of the "hairy" nature of the heap, the fact that VM tries to adapt to your app but doesn't always get it right, and the cost of the VM itself (e.g. generated code and additional data structures)]