That's more like it.  :)

On Mon, Mar 30, 2009 at 7:09 PM, Yingfeng Zhang <yingfeng.zh...@gmail.com>wrote:

> Thanks for feedbacks.
> I agree with what your points.I use vector<string> because it had already
> been used on existing platform.
>
> A newer test of comparing vector<int> has the following result:
>
> It takes 1.9 seconds for boost to serilize vector<int> of size 10000000 !
>
> It takes 4.71 seconds for boost to deserilize vector<int> of size 10000000
> !
>
> It takes 0.47 seconds for protocol-buffer to serilize  vector<int>of size
> 10000000 !
>
> It takes 0.45 seconds for protocol-buffer to deserilize  vector<int> of
> size 10000000 !
>
>
>
> Best
>
>
>
> On Tue, Mar 31, 2009 at 2:07 AM, Kenton Varda <ken...@google.com> wrote:
>
>> Several points:
>>
>> * Some of your test cases seem to be parsing from or serializing to files.
>>  This may be measuring file I/O performance more than it is measuring the
>> respective serialization libraries.  Even though you are using clock() to
>> measure time, simply setting up file I/O operations involves syscalls and
>> copying that could take some CPU time to execute.  Try parsing from and
>> serializing to in-memory buffers instead.  For protocol buffers you should
>> use ParseFromArray() and SerializeToArray() for maximum performance -- not
>> sure if boost has equivalents.
>>
>> * Your test generates different random data for the boost test vs. the
>> protobuf test.  For an accurate comparison, you really should use identical
>> data.
>>
>> * Finally, your test isn't a very interesting test case for protocol
>> buffers.  Parsing and serializing a lot of strings is going to be dominated
>> by the performance of memcpy().  You might notice that the actual
>> serialization step in your program takes much less time than even just
>> populating the message object.  It might be more interesting to try
>> serializing a message involving many different fields of different types.
>>
>>
>> I think the reason parsing ends up being much slower than serialization
>> for you is because it spends most of the time in malloc(), allocating
>> strings.  There are a few things you can do about this:
>>
>> 1) Reuse the same message object every time you parse.  It will then reuse
>> the same memory instead of allocating new memory.
>>
>> 2) Make sure you are not using a reference-counting string implementation.
>>  They are, ironically, very slow, due to the need for atomic operations.
>>
>> 3) Use Google's tcmalloc in place of your system's malloc.  It is probably
>> a lot faster.
>>
>> On Sun, Mar 29, 2009 at 9:32 PM, Yingfeng Zhang <yingfeng.zh...@gmail.com
>> > wrote:
>>
>>> Test files are attached
>>>
>>> Best
>>>
>>>
>>>
>>> On Mon, Mar 30, 2009 at 12:14 PM, Kenton Varda <ken...@google.com>wrote:
>>>
>>>> What does your .proto file look like?  And the code that uses it?
>>>>
>>>> On Sun, Mar 29, 2009 at 9:06 PM, Yingfeng <yingfeng.zh...@gmail.com>wrote:
>>>>
>>>>>
>>>>> Hi,
>>>>> We are looking for a fast mechanism for serialization/deserialization.
>>>>> Here is our comparison between pb and boost:
>>>>> We hope to serialize/deserialize data in std containers, such as:
>>>>>
>>>>> std::vector<std::string>
>>>>>
>>>>> Here is the data
>>>>> 10000000 strings are stored in the vector
>>>>>
>>>>> as to boost:
>>>>> Serialization: 3.8 s
>>>>> Deserialization: 6.89 s
>>>>>
>>>>> as to protocol buffers:
>>>>> Serialization: 4.59 s
>>>>> Deserialization: 0.47 s
>>>>>
>>>>> It seems pb performs much bettern than boost in deserialization,
>>>>> however it is even slower than boost in serialization. Could it be
>>>>> improved for serialization to be as fast as deserialization?
>>>>>
>>>>>
>>>>> >>>>>
>>>>>
>>>>
>>>
>>
>

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups 
"Protocol Buffers" group.
To post to this group, send email to protobuf@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
-~----------~----~----~----~------~----~------~--~---

Reply via email to