It doesn't have to be. CodedInputStream.newInstance() is very
expensive for small messages.
Eliminating the call yields much better results. For example:
Benchmarking benchmarks.GoogleSpeed$SpeedMessage1 with file ../
google_message1.dat
Deserialize from byte string: 20354111 iterations in 29.817s;
148.4305MB/s
Deserialize from byte array: 20406928 iterations in 29.825s;
148.77573MB/s
Deserialize from memory stream: 9682142 iterations in 29.936s;
70.32546MB/s
Deserialize from memory stream reusing CodedInputStream: 18493403
iterations in 30.029s; 133.90935MB/s
Using this new benchmark:
final CodedInputStream reuseCodedInputStream =
CodedInputStream.newInstance(inputStream);
benchmark("Deserialize from memory stream reusing
CodedInputStream", inputData.length, new Action() {
public void execute() throws IOException {
defaultMessage.newBuilderForType()
.mergeFrom(reuseCodedInputStream).build();
inputStream.reset();
reuseCodedInputStream.resetSizeCounter();
}
});
Which actually brings up a feature request -
MessageLite.Builder.mergeDelimitedFrom(InputStream) is too inefficient
for small streamed messages, since it creates a new CodedInputStream
(and 4KB buffer to go with it) every time. The addition of a
mergeDelimitedFrom(CodedInputStream) would be welcomed.
On Mar 8, 2:26 pm, Kenton Varda <[email protected]> wrote:
> Decoding from a "memory stream" is significantly slower than a byte array.
> The degree of the difference will depend on the data set. SpeedMessage1 is
> much smaller than SpeedMessage2, therefore differences in one-time costs in
> setting up the parser will be more prominent. Of course, different
> platforms and Java implementations will also show different results.
>
>
>
> On Mon, Mar 8, 2010 at 8:52 AM, Evan Jones <[email protected]> wrote:
> > On Mar 7, 2010, at 20:36 , Oliver Jowett wrote:
>
> >> 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
>
> >> I wonder what's happening in the first memory stream case to make it 3x
> >> slower than everything else?
>
> > I just dug up some results from the last time I was playing with
> > ProtoBench, and I got the results being slower, but not 3X. This was on
> > Linux, on a recent Intel Core i7 Xeon (Nehalem architecture), with
> > SpeedMessage1:
>
> > Deserialize from byte string: 25450873 iterations in 30.007s; 184.42299MB/s
> > Deserialize from byte array: 25368774 iterations in 29.745s; 185.44727MB/s
> > Deserialize from memory stream: 15248317 iterations in 29.285s;
> > 113.21699MB/s
>
> > Evan
>
> > --
> > Evan Jones
> >http://evanjones.ca/
>
> > --
> > 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]<protobuf%[email protected]
> > om>
> > .
> > For more options, visit this group at
> >http://groups.google.com/group/protobuf?hl=en.
--
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.
