The GC is killing me smalls

[thlorenz]

Abstract

The Problem

nodejs has first class support for streams, so it should be easy to stream lots of data right? Well there is a caveat. If you are streaming crazy amounts of data, say historical pricing info to lots of clients concurrently, you'll see some serious performance degredation.

Why?

Ask the Garbage Collector who is collecting all these objects you end up creating in order to send the data.

How do I know?

I tried this before in Haskell and the GC was killing me.

The Solution

We need to circumvent the GC and/or optimize the amount of objects we create and how they get collected.

In order to find out how to do this I'll proceed as follows:

1. Create a naive JavaScript implementation and measure it's performance to show that the GC is our bottleneck.
2. Create an implementation in pure C which allows me to manage my memory as I please in order to show the performance that is possible when the GC doesn't get in the way
3. I will try to be smarter about the JavaScript implementation. In order to come close, I'll investigate all kinds of tricks, i.e.:
   • find a way to use Buffers or similar to be able to manage memory and avoid the GC
   • optimize the format we use for our data (binary vs. JSON)
   • dig in to some v8-code in order to understand chrome's garbage collection better
   • investigate which tweaks are possible via command line flags

Since this is an experiment, I'm not sure which of these will work, but learning through trial and error is the purpose of this experiment.

The Talk

As an intro I'll explain what Garbage Collection is, the different ways it is implemented for different technologies and the problems it can cause. I will also give a quick primer on Memory Management as it is used in C applications.

In regards to the optimized JavaScript implementation, I will report on how close to the C implementation I got and what techniques I tried, which ones worked and which ones didn't. Lots of performance charts/graphs and code samples will accompany the presentation as well as a demo of the resulting application.

Finally I will list the tools/techniques I used to measure the performance of my JavaScript in order to equip attendees with the skills to find bottlenecks in their applications.

Speaker BIO

I have been working with nodejs and JavaScript for over 2 years mostly in my spare time and lately full time at Condé Nast.

The fast turnaround from idea to working module has proven addictive for me and led to lots of modules which ended up on github and/or npm. I also contribute to other awesome open source efforts like browserify to which I added source map support.

[techwraith]

Any chance you can narrow down the scope of this talk to ~20 minutes? I'm putting together the schedule for RejectJS on March 8th and would love to have this talk be a part of it.

[thlorenz]

The talk was never meant to be longer than that. However I didn't directly work on preparing for this (since it wasn't accepted), I focused on streams in general and libuv instead.

There is still a lot of work that remains in order to do the necessary experimentation, so it'd be impossible to get ready in time. Would you be open to have me talk about productivity or modularization instead?

I believe both of these topics to be very interesting and beneficial to the audience as well.

As an alternative I could talk about the engine that powers nodejs aka libuv. It did a lot of work in that area as well, part of which is visible as libuv-dox.