Re: [protobuf] Re: Any sample messages/data for optimization out there?
On Tue, Mar 9, 2010 at 3:41 AM, Evan Jones wrote: > On Mar 9, 2010, at 3:21 , Paul Rudd wrote: > >> 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. >> > > > You can do this yourself. I think the following would work: > > int length = inputStream.readRawVarint32(); > int oldLimit = inputStream.pushLimit(length); > builder.mergeFrom(inputStream); > inputStream.popLimit(oldLimit); Yep, that works. In fact, you can even do the above in one line: codedInput.readMessage(builder, ExtensionRegistryLite.getEmptyRegistry()); It turns out that since readMessage() assumes the tag was already read, it parses the exact same format that mergeDelimitedFrom() does. -- 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 protobuf+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/protobuf?hl=en.
Re: [protobuf] Re: Any sample messages/data for optimization out there?
On Mar 9, 2010, at 3:21 , Paul Rudd wrote: 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. You can do this yourself. I think the following would work: int length = inputStream.readRawVarint32(); int oldLimit = inputStream.pushLimit(length); builder.mergeFrom(inputStream); inputStream.popLimit(oldLimit); 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 proto...@googlegroups.com. To unsubscribe from this group, send email to protobuf+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/protobuf?hl=en.
[protobuf] Re: Any sample messages/data for optimization out there?
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 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 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 proto...@googlegroups.com.
> > To unsubscribe from this group, send email to
> > protobuf+unsubscr...@googlegroups.com > 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 proto...@googlegroups.com.
To unsubscribe from this group, send email to
protobuf+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/protobuf?hl=en.
Re: [protobuf] Re: Any sample messages/data for optimization out there?
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 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 proto...@googlegroups.com. > To unsubscribe from this group, send email to > protobuf+unsubscr...@googlegroups.com > . > 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 proto...@googlegroups.com. To unsubscribe from this group, send email to protobuf+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/protobuf?hl=en.
Re: [protobuf] Re: Any sample messages/data for optimization out there?
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 proto...@googlegroups.com. To unsubscribe from this group, send email to protobuf+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/protobuf?hl=en.
[protobuf] Re: Any sample messages/data for optimization out there?
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?
-O
--
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
protobuf+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/protobuf?hl=en.
