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.
