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.
