Hello,
FWIW, this is the boilerplate I use for my proto3.0.0 project. It depends
on GetTypeName() whose future is uncertain in the lite runtime. It appears
to work in one of my tests but I am not sure if I am missing something
subtle. I'm using SerializeWithCachedSizesToArray because I learned that
it is faster for large messages because it does not compute the size twice.
static void PackInto(google::protobuf::Any* target, const
google::protobuf::MessageLite& msg)
{
int msg_size = msg.ByteSize();
char* msg_buffer = new char[msg_size];
msg.SerializeWithCachedSizesToArray((google::protobuf::uint8*)msg_buffer);
//avoids double
target->set_type_url(msg.GetTypeName());
target->set_value(msg_buffer,msg_size);
delete[] msg_buffer;
}
static void UnpackFrom(const google::protobuf::Any& source,
google::protobuf::MessageLite* msg)
{
EXPECT_EQ(source.type_url(), msg->GetTypeName()); //Could be converted
to an assert or CHECK style macro in a non-test project
msg->ParseFromArray(source.value().c_str(), source.value().size());
}
Thanks,
Mohamed Koubaa
Software Developer
ANSYS Inc
On Tue, Nov 29, 2016 at 8:22 PM, Adam Cozzette <[email protected]> wrote:
> Right now there doesn't seem to be a consensus around adding built-in
> support for Any in the lite runtime, so I suspect that the status quo will
> probably remain for now. If you would like to use Any with the lite
> runtime, I think it's probably best to just manually serialize and parse to
> and from your Any fields, since that will work even if it involves a little
> extra boilerplate.
>
> On Tue, Nov 29, 2016 at 11:20 AM, Mohamed Koubaa <[email protected]
> > wrote:
>
>> Hello,
>>
>> I am sorry to bring back an old thread, but the outcome is not clear. Is
>> there either an intent or any ongoing work to support Any types with the
>> lite runtime?
>>
>> Best Regards,
>> Mohamed Koubaa
>> Software Developer
>> ANSYS Inc
>>
>> On Mon, Oct 10, 2016 at 3:00 PM, 'Adam Cozzette' via Protocol Buffers <
>> [email protected]> wrote:
>>
>>>
>>> On Fri, Oct 7, 2016 at 2:16 PM, Arpit Baldeva <[email protected]>
>>> wrote:
>>>
>>>> Thanks for the info.
>>>>
>>>> I feel like without pack/unpack/Is method, the utility of Any will
>>>> diminish. For example, the rpc status proto (
>>>> https://github.com/googleapis/googleapis/blob/master/google
>>>> /rpc/status.proto) uses repeated Any field. It'd not be possible to
>>>> write code like one described here - https://developers.google.co
>>>> m/protocol-buffers/docs/proto3#any because you won't know if it is
>>>> safe to convert value to a give message. I also came across this post after
>>>> my post which marks the request as a bug currently -
>>>> https://github.com/google/protobuf/issues/1974
>>>>
>>>
>>> What you're saying makes sense, we might want to consider just updating
>>> Any to have first-class support for MessageLite. In C++ this would be
>>> straightforward but in Java, for example, we would need to think carefully
>>> about how to do it because in Java lite we don't currently have the message
>>> names available at runtime.
>>>
>>> Regarding the future of GetTypeName, though it has overhead, feel like
>>>> it could have many utilities outside of the Any support as well. I don't
>>>> have concrete use case in mind though as I am just starting on protobuf.
>>>> This brings another important question that I was wondering if somebody
>>>> already has data around. There are two options for reducing code bloat. One
>>>> is Lite and another is code_size. I understand that lite reduces code bloat
>>>> by removing descriptors/reflections related code (thereby reducing the
>>>> library size) and code_size reduces the code bloat by generating less code
>>>> per message but puts descriptors/reflectors back in(shared code). And the
>>>> recommendation is to choose code_size option if number of message are much
>>>> higher compared to the overhead caused by the size of lib. Are there any
>>>> benchmarks around what the size of the library is (and lite version) and
>>>> what is the per message overhead saved by the code_size option? And the
>>>> performance drop with code_size option?
>>>>
>>>
>>> Here's one way to break it down.
>>>
>>> SPEED:
>>> - Fixed overhead of full runtime (e.g. the Message class)
>>> - Per-message overhead of generated parsing/serialization code
>>> - Per-message overhead of generated descriptors
>>>
>>> LITE_RUNTIME:
>>> - Fixed overhead of lite runtime (e.g. includes MessageLite but not
>>> Message)
>>> - Per-message overhead of generated parsing/serialization code
>>>
>>> CODE_SIZE:
>>> - Fixed overhead of full runtime (e.g. the Message class)
>>> - Per-message overhead of generated descriptors
>>>
>>> SPEED and LITE_RUNTIME should be about the same speed because they both
>>> benefit from the fast generated code for parsing and serialization, while
>>> CODE_SIZE is much slower because it relies on reflection instead of
>>> generated code. My impression is that CODE_SIZE is not really a good choice
>>> unless you have an unusual situation where you have a large number of
>>> protos and are really tight on code size. A basic rule of thumb would be to
>>> use the default (SPEED) on servers and LITE_RUNTIME on mobile.
>>>
>>> I'm not sure offhand of the actual numbers for how binary size and speed
>>> differ between the three choices--Gerben (CC'd), do you happen to know some
>>> numbers for this question?
>>>
>>> --
>>> You received this message because you are subscribed to the Google
>>> Groups "Protocol Buffers" group.
>>> To unsubscribe from this group and stop receiving emails from it, send
>>> an email to [email protected].
>>> To post to this group, send email to [email protected].
>>> Visit this group at https://groups.google.com/group/protobuf.
>>> For more options, visit https://groups.google.com/d/optout.
>>>
>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "Protocol Buffers" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to [email protected].
>> To post to this group, send email to [email protected].
>> Visit this group at https://groups.google.com/group/protobuf.
>> For more options, visit https://groups.google.com/d/optout.
>>
>
>
--
You received this message because you are subscribed to the Google Groups
"Protocol Buffers" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To post to this group, send email to [email protected].
Visit this group at https://groups.google.com/group/protobuf.
For more options, visit https://groups.google.com/d/optout.
