Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

JavaNano: Reason for ByteBuffer in CodedOutputByteBufferNano ? #511

Closed
ennerf opened this issue Jun 18, 2015 · 1 comment
Closed

JavaNano: Reason for ByteBuffer in CodedOutputByteBufferNano ? #511

ennerf opened this issue Jun 18, 2015 · 1 comment

Comments

@ennerf
Copy link
Contributor

ennerf commented Jun 18, 2015

Is there a reason why CodedOutputByteBufferNano was switched to use ByteBuffer, but CodedInputByteBufferNano is still working on byte arrays? For our particular use case (many varint types and forced to consume byte[]) the performance dropped quite a bit.

I've uploaded a simple benchmark here (https://gist.github.com/ennerf/45809ef405a4a56a285b). The test value results in a 2 byte varint. It gets worse for larger values.

ByteBuffer vs byte[]:
writeRawLittleEndian32 dropped 19%
writeRawVarint32 dropped 41%

DirectByteBuffer vs byte[]:
writeRawLittleEndian32 gained 38%
writeRawVarint32 dropped 22%

Thanks
@ennerf ennerf mentioned this issue Jun 25, 2015
Closed
@liujisi
Copy link
Contributor

liujisi commented Mar 8, 2017

Closing it now. We are in general in favor of using lite rather than nano since 3.0 release, and don't have plans to further improve javanano.

@liujisi liujisi closed this as completed Mar 8, 2017
taoso pushed a commit to taoso/protobuf that referenced this issue Aug 1, 2018
@dsnet
proto: treat bad wire types as unknown fields (protocolbuffers#511)
e6af52b 
Previously, an error was returned during unmarshal when a wiretype
was encountered that did not match the expected wiretype.

In order to match the behavior of the C++ and Python implementations,
we no longer return an error and instead store the bad wire fragment
as an unknown field (or skip them if unknown field preservation is disabled).

The generator still produces code that references ErrInternalBadWireType
for unmarshal logic for oneof fields.
However, the current proto package does not use the generated unmarshalers
for oneofs, so their existence has no bearing on unmarshal semantics.

Cleaning up the generator to stop producing these is future work.
taoso pushed a commit to taoso/protobuf that referenced this issue Aug 1, 2018
@dsnet
proto: do not allow unknown fields to satisfy required field bit (pro…
91cccdb 
…tocolbuffers#565)

A prior changed (see protocolbuffers#511) allows Unmarshal to treat fields with
unknown wire types with known tags as unknown fields.
When doing so, we must be careful not to set the required field bit.

For example, suppose we have:
	message Foo { require fixed32 my_field = 1; }

Then parsing a message with a field of type varint and tag 1 should
not satisfy the required that Foo.my_field be set.
adellahlou pushed a commit to adellahlou/protobuf that referenced this issue Apr 20, 2023
@dcodeIO
prepublish script for bin files, fixes protocolbuffers#511; swallow e…
6e5fdb6 
…num value options (no wrapper), fixes protocolbuffers#510; expose zero on LongBits, fixes protocolbuffers#508
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
3 participants
@liujisi @ennerf @xfxyjwf