I have this project, called Memcached.Js, which is a port of Memcached server to Node.js.
I\'ve been playing arround with strings and buffers, comparing memory footp
Buffer.slice is expensive in node. I've found that the pattern:
buffer.slice(start, end).toString(encoding)
was more than 10 times slower than the pattern:
buffer.toString(encoding, start, end)
Even though slice doesn't allocate any new buffer, it seems to incur a significant cost. From a cursory look at the code, my guess is that exposing the externally allocated buffer to v8 (via SetIndexedPropertiesToExternalArrayData) causes it to have to update its generated code for the buffer object.
Once created (or sliced), buffers seem fast. So creating bigger buffers instead of lots of little ones, and reusing when possible seems like a reasonable strategy for performance.
More thoughts on this: http://geochap.wordpress.com/2011/05/03/node-buffers/
Strings are built-in to V8, and allocate memory within the VM. Buffers were added not to make all string operations faster, but to represent binary data, where as Strings are unicode.
When writing large amounts of data to a socket, it's much more efficient to have that data in binary format, vs having to convert from unicode.
So for common operations, like concat, I'm not surprised Strings are faster.