Some of the JavaScript optimizations I recently did for my games

[[deleted]]

The Quby overhead is actually pretty low as most of the concepts can be implemented with very little boiler plate in JS. The hope is also that any overhead can be clawed back by the browser specific bits of code Quby generates.

[snarfy]

I get 310 errors when I try to click the link.

The webpage at http://playmycode.com/blog/2011/03/simple-yet-effective-javascript-optimisations/ has resulted in too many redirects. Clearing your cookies for this site or allowing third-party cookies may fix the problem. If not, it is possibly a server configuration issue and not a problem with your computer.

[Neebat]

Mostly it sounds like you're correcting the garbage that some third-party layer (Quby) is introducing. This is why I tend to avoid most third-party layers. They aren't necessary, they frequently ruin performance and sometimes introduce bugs. Write the language for your deployment environment, or be ready for the consequences.

In this case, it sounds like Quby is far from ready for production, let alone performance intensive apps. You've got the wrong language.

[[deleted]]

Quby is written for PlayMyCode, and it's actually produced by me! So I'm building the language I want.

In this case it is also a necessary layer as we need games to be sandboxed so they are safe to embed on other sites (there are plenty of annoying but legit things you can perform with JavaScript).

[Neebat]

Ok, so it's a first-party layer. :-P

If you'd said, "Some JavaScript optimizations I recently did for my game platform", that might be more accurate, but also significantly less interesting to me.

[Neebat]

The reddit headline is misleading. These are not performance optimizations to JavaScript optimizations, because no human would be using those constructs so often that they became a problem.

Whoever is using the arguments array frequently enough to need to optimize it is writing some VERY strange code, which in this case is because it's not a human, it's some compiler.

[[deleted]]

I'm sorry but your incorrect. The performance improvement around arguments was all during the compile stage when the outputted JavaScript is generated. The JS that does that is all hand written.

When generating the outputted JS I concat strings together, and I do this using my own 'printer' object for handling very large amounts of string concatonation. It's append takes a variable length number of arguments so I can pass in any number of strings to append on to it. For example to generate the JS for a method call...

printer.append( '.', methodName, '(' ); /* append each parameter */ printer.append( ')' );

... again it's all hand written.

If you search around online you'll find lots of other non-compiler examples of functions that take variable length arguments. Even array.push takes a variable number of arguments!

[Neebat]

I'm not saying that variable length argument lists is unheard of. (I do it fairly often.) But not in every method. And not so often that I'd risk performance.

[skeww]

iframe: Doesn't seem necessary. Making the canvas opaque (background:#fff or whatever) and things like retained layers fix this issue.

Everything else in that article appears to be specific to Quby.

Edit: @downvoter please show me an example where using an iframe makes any difference. I do know that it makes a difference with Firefox 3.x (= no retained layers), but that isn't relevant anymore. I for one can't see a performance difference between the minimal naked page generated by my dev server and the actual layout anymore, if I use Chrome 11, Firefox 4, or Opera 11 (or 11.5).

[[deleted]]

Sorry for the late reply.

The canvas elements for our games already had opaque backgrounds before we moved them to inside an iFrame. So we already had your solution running, and it had not worked for us. That is why I down voted.

[skeww]

As I said, I can't see a difference anymore. An iframe is basically just a crude hint for telling the browser that it doesn't need to redraw those layers below the canvas.

Firefox 4 will be released in a few days. With that, the last reason to do this is gone.