I am using add_person.cc provided in the sample file. The only change I have
done is,
a while loop around this code. So it's same record inserted multiple times.
// Write the new address book back to disk.fstream output(argv[1], ios::out
| ios::trunc | ios::binary);
*int nRecords = 100000;*
*while ( nRecords-- )*
*{* if (!address_book.SerializeToOstream(&output)) {
cerr << "Failed to write address book." << endl;
return -1;
}*}*
On Mon, Mar 22, 2010 at 1:34 PM, Daniel Wright <dwri...@google.com> wrote:
> The most likely cause is a bug in your code where there's something you
> aren't clearing each time you write a record, so at each iteration in your
> loop, the record you're writing is getting bigger. Of course I can't say
> for sure without seeing the code.
>
> Daniel
>
> On Mon, Mar 22, 2010 at 1:13 PM, Vinit Mahedia <shortempe...@gmail.com>wrote:
>
>> Hi Jason,
>>
>> Thanks for the quick reply.
>>
>> I am not surprised by the increase in file size, But I am under impression
>> that If I insert the same record
>> thousand times, the size of file should be large accordingly,
>>
>> e.g, assume that one record generates the file of size 32 bytes; with1024
>> records should sum up to 32K
>> size or close to that but it does not and that is why I am surprised. The
>> growth in size is not linear and
>> that was the reason I posted my findings. I am a student so might be
>> missing a small concept or anything
>> here, if so, apologies in advance for taking your time.
>>
>> Once again appreciate your help,
>>
>>
>>
>> On Mon, Mar 22, 2010 at 12:42 PM, Jason Hsueh <jas...@google.com> wrote:
>>
>>> If you're measuring using sizeof(), you won't account for memory
>>> allocated by subobjects (strings and submessages are stored as pointers).
>>> You should use Message::SpaceUsed() instead. The inmemory vs serialized size
>>> is going to depend on your proto definition and how you use it. If you have
>>> a lot of optional fields, but only set one of them, the serialized size will
>>> likely be much smaller than the in memory size. If you have lots of large
>>> strings, they're probably going to be pretty close since both sizes will be
>>> dominated by the actual bytes of the strings.
>>>
>>> It sounds like you are surprised that the serialized size increases as
>>> you increase the number of records. What exactly do you expect to happen
>>> here?
>>>
>>>
>>> On Mon, Mar 22, 2010 at 12:15 PM, Vinit <shortempe...@gmail.com> wrote:
>>>
>>>> I was testing to see the upper limit for numbers of records in one
>>>> file.
>>>> I used the addressbook example, and I noticed that for one record
>>>> it generates file double the size.
>>>>
>>>> for ex. size of the class I was putting into it was 48 bytes and the
>>>> file
>>>> was of 97 bytes on ubuntu 9.10.
>>>>
>>>> Now, I go test it with 1000 records bang! it goes many fold and with
>>>> records in hundreds of thousands, file size increases in many folds.
>>>>
>>>> Has anyone investigated around this area ? I did not note down the
>>>> exact numbers as I thought someone should already have done it.
>>>>
>>>> Please let me know if you want the detail test numbers, I can run
>>>> through it again and provide you with information.
>>>>
>>>> --
>>>> 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<protobuf%2bunsubscr...@googlegroups.com>
>>>> .
>>>> For more options, visit this group at
>>>> http://groups.google.com/group/protobuf?hl=en.
>>>>
>>>>
>>>
>>
>>
>> --
>> Vinit
>>
>> --
>> 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<protobuf%2bunsubscr...@googlegroups.com>
>> .
>> For more options, visit this group at
>> http://groups.google.com/group/protobuf?hl=en.
>>
>
>
--
Vinit
--
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.
