Show me that avoiding the creation of a single JavaScript object significantly affects the overhead of your program (which is presumably doing some IO, and copying some data around somewhere), and we'll consider either blessing it as public, or optimizing the call out in some other way. But lacking data, I'm skeptical that it's even relevant.
There's nothing stopping you from using it, of course. Just be aware that it makes your program much more brittle. On Thu, Apr 19, 2012 at 23:28, Joran Greef <[email protected]> wrote: > It does instantiate a new Buffer object though and I would like to avoid as > many instantiations as possible to reduce gc overhead. My parser is the only > one attached to the socket, and could easily accept an ondata with offset > and length arguments. I would prefer if this were part of the api since it > gives closer access to the metal, albeit every so slight. > > > On Thursday, April 19, 2012 7:57:28 PM UTC+2, mscdex wrote: >> >> On Apr 19, 12:43 pm, Joran Greef <[email protected]> wrote: >> > Is it safe to use ondata to avoid the buffer.slice overhead introduced >> > when >> > otherwise calling on('data') callbacks? >> >> How much overhead are you seeing with buffer.slice()? It references >> the same chunk of memory as the original and does not do any copying. > > > On Thursday, April 19, 2012 7:57:28 PM UTC+2, mscdex wrote: >> >> On Apr 19, 12:43 pm, Joran Greef <[email protected]> wrote: >> > Is it safe to use ondata to avoid the buffer.slice overhead introduced >> > when >> > otherwise calling on('data') callbacks? >> >> How much overhead are you seeing with buffer.slice()? It references >> the same chunk of memory as the original and does not do any copying.
