SimonHF's Blog

Just another site

node.js versus Lua “Hello World” — Postmortem October 23, 2010

Filed under: Uncategorized — simonhf @ 4:54 pm
Tags: , , , , , , ,

Last time I performance tested an experimental version of the soon to be released SXELua against node.js. What I found is that SXELua is 2.9 times faster with the simple “Hello World” test. However, what I didn’t mention is why SXELua is so much faster. When first running the test with a very early version of SXELua then the results were about half as good as the node.js+net+crcr results! The reason for this is the way that Lua handles its strings. During the simple “Hello World” test then HTTP queries are read using the following code path: libev C code calls SXE C code which read()s the HTTP query string and then passes the string to the Lua read event handler. During this last step then Lua ‘internalizes’ the string. This means that Lua does a quick hash (alert: more expensive operation) over the string, allocates memory for it, and copies it… and later unfortunately garbage collects it too. All these operations take lots of CPU. The simple “Hello World” benchmark sends 500,000 HTTP query strings which are each 199 bytes. So you can imagine how even heavily optimized string internalization code might get bogged down with such a large number of strings to internalize and eventually garbage collect. In-fact, take any small overhead and multiply it by 500,000 and suddenly it becomes a large overhead. So in the end Neil change SXELua so that Lua’s string handling code isn’t used and instead Lua calls back out to SXE C code to do all its string handling. This works very fast because C is very fast, and calling C from Lua or vice-versa is very fast, and SXE itself uses neither malloc() nor dynamic memory garbage collection techniques while processing queries. So this means that SXELua is limited to only using an if… then… call subset of syntax of Lua? Yes! And if you think about it then this makes perfect sense. Why? Because it’s faster to do the generic ‘heavy lifting’ — for example, string — operations in C than it is in Lua… especially if this avoids internalization and garbage collection. The part that I’d like to rapidly code in Lua is the lighter-weight, non-generic, business logic of the program. In the end this works out really well and SXELua is 2.9 times faster than the node.js simple “Hello World” test. This is probably mainly because node.js has three different types of overhead in this particular test: 1. JavaScript string manipulation code is slower than C string manipulation code and this difference gets multiplied 500,000 times. 2. JavaScript creates 500,000 strings. 3. JavaScript garbage collects 500,000 strings. So it’s easy to see why both the SXELua and SXE simple “Hello World” tests are 2.9 times and 3.4 times faster than the node.js equivalent.


2 Responses to “node.js versus Lua “Hello World” — Postmortem”

  1. g-wan vs libsxe: libsxe wins performance, opensource and friendly developer. I like to see libsxe as a feasible solution with Go to handle websocket and alternative to Java NIO (one of which xsocket is use in my project).

    By integrated in Google Go, I feel how much powerful its can go.

    • simonhf Says:

      Hi James, Thanks for the message. I have been reading up on websockets and would love to do a ‘hello world’ libsxe websocket bake-off… but against which websocket server? And do you know of a perf tool like ab which handles websockets? Regarding Google Go then I don’t know much about it. What makes a language suitable for pairing with libsxe is how fast it can be called from C and vice-versa. For example, it’s relatively slow to call a language like Perl from C. Lua is interesting because it’s one of the fastest scripting languages to be called from C. Is it fast to call Go from C?

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s