Code structure and efficiency: Tips and Tricks

[hellspawn_bg]

Recently I have been following an ongoing discussion regarding mobile performance and efficiency. One of the recommendations that caught my eye was to avoid classes and prototyping altogether because they can slow down the performance significantly. So far I have structured my code by creating separate class objects in different files by using prototypes.

class = function () {}class.prototype.myMethod1 = function () {     console.log('myMethod');}class.prototype.myMethod2 = function () {     console.log('myMethod2');}

In this regard, I am wondering what is the recommended and most efficient way to structure your code? Perhaps the more experienced users can share something from their bag of tricks.

 

Thanks

[lewster32]

I don't think the structure of your code in terms of how you choose to go about organising things into objects, pseudo-classes and so on has much impact at all on performance, but it will have a huge impact on manageability, and with unmanageable code performance is likely to suffer as you begin to lose track of what's going on. I'd personally suggest you stick with your current style or, at the very least, test the alternatives in a granular way to see how they impact performance. My feeling is that it'll have a negligible impact (if any) compared to, for instance, what you put in the update function.

[brejep]

Both PIXI and Phaser and a lot of other libraries use the prototypal inheritance pattern you have described, so you can't get away from it entirely.

 

The statement is rather broad, see for example, the top answer here: http://stackoverflow.com/questions/3493252/javascript-prototype-operator-performance-saves-memory-but-is-it-faster which suggests prototype can be faster than other options.  Prototype will also often save memory, another important factor on phones.

 

I think an important thing to note here is the rule of premature optimization. I see a lot of developers worrying about performance far too early at the expense of readable and maintainable code.

 

If you are struggling with performance on phones, I'd do some performance tests and see which bits of your code are struggling. Chrome dev tools or similar can help here. Start by looking at looped code that is doing a lot of work - calling functions and changing a lot of properties and see if this can be optimized.

 

Also, as rendering is often a bottleneck, I'd look at graphics, any way they can be reduced in size? I suggest pngquant and a good build tool (like gulp or grunt) to create optimized assets every time you build.

 

If you do want to move away from prototype, one option you can think about is Object.create(null); As that will create an object without a prototype. So similar code to yours above would be:

function myMethod1() {   console.log('myMethod1');}function myMethod2() {  console.log('myMethod2');}var klass = Object.create(null);klass.myMethod1 = myMethod1;klass.myMethod2 = myMethod2;// clone the objectvar instance1 = Object.create(klass);var instance2 = Object.create(klass); 

Be mindful that these objects will not have functions like hasOwnProperty or isPrototypeOf and may have properties that don't show up in console.log or console.dir as well.

[stormwarestudios]

I prefer (and have implemented) AMD for modularization in my game engine, using Dojo for the application layer of the program. It makes code maintenance significantly simple, at a relative small performance cost (mainly at module load-time, whose problems can be mitigated through other measures like compilation, caching and various other optimization techniques.