Ryan, just a quick question: couldn't external strings solve the problem for you? They sound pretty much like Buffer you describe as far as I can judge from your email.
yours, anton. On Thu, Apr 22, 2010 at 3:03 AM, <[email protected]> wrote: > I'm experiencing a bottleneck in my application, Node, when writing > strings to socket. Here is a benchmark where I create a web server and > write a string of X bytes as a response. Compared to other systems > which can do write() directly from the string buffer to file > descriptor, Node is quite slow: > > http://s3.amazonaws.com/four.livejournal/20100421/response_string.png > > I've created a "Buffer" object which allocates memory outside of V8's > heap and allows one to write directly to the socket. When doing the > benchmark with a "Buffer" the results are quite good: > > http://s3.amazonaws.com/four.livejournal/20100421/response_buffer.png > > So it's clear that the memcpy of a string out of V8 is the bottleneck > in the previous benchmark, not the networking code. Using "Buffer" is > a fine for certain situations but optimizing for strings is still > important. > > I acknowledge that V8 cannot give raw memory access to strings due to > the fact that objects get moved around - and that in most cases > they're 16bit arrays, so they'd need to be UTF-8 encoded first. > However, what would people think about passing the write system call > to V8? I imagine a function which would take a string and file > descriptor, utf8 encode it in the v8 heap (using i::ByteArray), and > write that data out to the kernel, returning the number of bytes > written. Something like this: > > ssize_t String::SocketWriteUtf8 (int fd, size_t offset); > > The second time SocketWriteUtf8() was called, it wouldn't need to > re-encode the string, it would just use the existing data. > > -- > v8-users mailing list > [email protected] > http://groups.google.com/group/v8-users > -- v8-users mailing list [email protected] http://groups.google.com/group/v8-users
