The author mentions defensive object cloning, which is, in general, an unpleasant way of doing things. Using immutable data structures makes for a far saner development experience (although with Javascript as the underlying target, it probably means some automatic defensive copying anyway...).
Using mutable state obviously generates far, far less garbage, and we've run into all sort of problems of bumping up against the GC in trying to have fast-enough javascript, so it is tempting from a performance POV. Would be wonderful if immutable structures can eventually co-exist nicely with GC implementations.
Unfortunately there aren't any particularly efficient ways to do immutable values in JS right now. readonly properties tend to behave in poor ways (like silently discarding attempted writes, or slowing down jitted code) and immutability forces you to create way more object instances than you would otherwise (which, as the post mentions, tends to perform poorly due to the relative immaturity of JS GCs.)
At this point I consider this to be a bigger problem than it was when I wrote about it [1]. On the upside, it's possible to use tools like Emscripten or LLJS to produce JavaScript code that doesn't suffer from these downsides because it doesn't rely on the JavaScript GC or heap, but that introduces its own issues.
Ultimately, JS engines either need dramatically better garbage collectors or, the language needs to evolve to the point that an ordinary piece of JavaScript isn't going to place tons of pressure on the collector. Proposals like Binary Data [2] will help pave the way here but it may ultimately take the addition of value types that behave like structs in C/C#.
I'm a web developer, but am just about to jump into making a multiplayer HTML5 game, just for fun.
But after reading this post, and the one linked at the bottom [1], I'm thinking maybe this is going to be pretty valuable professionally. It should give insight from a completely different vantage point on what it means to write good code. By the way, you really should read that other post, too. It offers some interesting ideas to think about.
>If you're going to deploy a long running node application that is going to be running a constant load, don't deploy it to either: A really low budget VPS
My multi-user node.js chatroom (http://ponyplace.ajf.me/) sustains around 60 concurrent users at any given time on a $5/month (not oversold) VPS. It can sustain a lot more than that too (151 at its highest yet after a 4chan raid).
The secret I find is in not letting your web server gobble up your memory. Don't use Apache, for example. I use nginx.
Hey, I noticed the traffic spike and came to say hello.
The thing about a chatroom and load, is that your server is effectively just message passing, and if there is any CPU spike, that is all it is - a spike, which VPSs for the most part are fine with.
When you are executing physics and logic 30 times a second constantly regardless of load (so I made a mistake in phrasing there in my blog post), then you will be throttled on a cheap VPS because you're no longer being a good citizen - which was my point in that post if I recall correctly.
To my recollection, this hasn't got much to do with memory at all. I hope this clarifies what I meant to say a bit more.
Yeah, that's pretty much it - I don't really want to keep dozens of domain names and DNS entries for pet projects lying around when they're only going to get 10 hits a day and the code is all available :-)
Using mutable state obviously generates far, far less garbage, and we've run into all sort of problems of bumping up against the GC in trying to have fast-enough javascript, so it is tempting from a performance POV. Would be wonderful if immutable structures can eventually co-exist nicely with GC implementations.
Great article, thanks for writing it!