Oliver Jowett wrote:
> (For
> example, I wonder if the Java code could benefit from the
> switch-prediction tricks that the C++ code does?)

FWIW, I hacked something together to test this, producing code that
looks like this:

>         while (true) {
>           int tag = input.readTag();
>           switch (tag) {
>             case 10: {
>               setField1(input.readString());
>               if (!input.expectTag(16)) break;
>             }
>             case 16: {
>               setField2(input.readInt32());
>               if (!input.expectTag(24)) break;
>             }
>             case 24: {
>               setField3(input.readInt32());
>               if (!input.expectTag(34)) break;
>             }

where CodedInputStream.expectTag() behaves like the C++ equivalent.

But it made <1% difference according to ProtoBench, down in the
measurement noise - it was actually slower in some cases.

There is also something strange going on with stream decoding. This is
from a plain svn build without the above changes:

> Benchmarking benchmarks.GoogleSpeed$SpeedMessage1 with file 
> google_message1.dat
> Deserialize from byte string: 17471413 iterations in 30.074s; 126.3199MB/s
> Deserialize from byte array: 17389320 iterations in 30.009s; 125.99868MB/s
> Deserialize from memory stream: 5050944 iterations in 29.372s; 37.391594MB/s
> Benchmarking benchmarks.GoogleSpeed$SpeedMessage2 with file 
> google_message2.dat
> Deserialize from byte string: 40052 iterations in 29.988s; 107.7192MB/s
> Deserialize from byte array: 39587 iterations in 29.678s; 107.5807MB/s
> Deserialize from memory stream: 40117 iterations in 29.9s; 108.21157MB/s

I wonder what's happening in the first memory stream case to make it 3x
slower than everything else?


You received this message because you are subscribed to the Google Groups 
"Protocol Buffers" group.
To post to this group, send email to proto...@googlegroups.com.
To unsubscribe from this group, send email to 
For more options, visit this group at 

Reply via email to