On Jan 11, 9:25 pm, Evan Jones <[email protected]> wrote: > This is a disadvantage, but it makes things much easier: it means the > buffer used to read data can be recycled for the next message. Without > this copy, the library would need to do complicated tracking of chunks > of memory to determine if they are "in use" or not. I read in several places that allocating objects in java rather than reusing is not so bad. The garbage collector is smart enough to take care of it.
> However, now that you mention it: in the case of big buffers, > CodedInputStream.readBytes() gets called, which currently makes 2 > copies of the data (it calls readRawBytes() then calls > ByteString.copyFrom()). This could probably be "fixed" in > CodedInputStream.readBytes(), which might improve performance a fair > bit. I'll put this on my TODO list of things to look at, since I think > my code does this pretty frequently. ok, thanks. > > The copy cannot be avoided because it makes the API simpler (thread- > safety, don't need to worry about the ByteBuffer being accidentally > changed, etc). The latest version of Protocol Buffers in Subversion > has ByteString.copyFrom(ByteBuffer) which will do what you want > efficiently. > I want to avoid copying data as much as possible (I'm aware it will not be possible to eliminate it altogether). I thought it wouldn't be so difficult to put an option in a message definition that will make protoc generate ByteBuffer fields instead of ByteString. Then with a corresponding method in CodedInput/OutputStream it should work, right? -- You received this message because you are subscribed to the Google Groups "Protocol Buffers" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/protobuf?hl=en.
