On Fri, Oct 18, 2019 at 6:43 PM Nadav Samet <thes...@gmail.com
> Hi Elias,
> You are bringing up two issues: (1) generated code size and (2) preservation of unknown fields during serialization/deserialization.
> For (1):
>> Maybe I'd keep some functionality such as withName() and getName().
>> Maybe I'd add some serialization features. But I don't really make use
>> of the other features and they really just bloat everything too much.
> I think that the main optional feature that you have not listed is lenses, which you can turn off by passing the "no_lenses" option to the generator, or set the option "lenses: false" as a file-level or package-level option.
> t has been requested in the past to provide an option to not generate `withX` and `clearX` - I know they contribute quadratically (in number of fields within each message) to the code size: each withX method calls copy() which access all fields.
I haven't looked at a recent version of the project (my apologies!)
but it's good that you have an option to disable the lenses feature.
> Can you be more specific about the "other features" that we can make optional? Maybe we can consider not generating descriptors as well, though I am doubtful this is going to substantially reduce code size.
Perhaps disabling the
writeTo/mergeFrom/serializedSize/getField/fromFieldsMap would reduce
code size dramatically.
Here's what I see with a typical Protobuf class in terms of class count:
fromFieldsMap - 4 classes
serializedSize - 2
getField - 6
toJavaProto - 10
writeTo - 8
lenses - 33
Each class seems to be about 1-2 kilobytes. Scala 2.11 here.
I do wonder if Scala is going to reduce code size in a future release,
so perhaps this is an unnecessary optimization looking ahead?
> It also sounds like you are willing to tradeoff performance for code size by delegating serialization/deserialization to Java and perform conversion. Is that right?
I think so. I haven't checked every API, but 90% of my APIs don't
require speed in de/serialization.
> For (2):
> ScalaPB has an option to preserve unknown fields, but it is disabled by default in 0.9.x. This default is planned to change in a future minor version to match the behavior of the Java implementation. In the mean time, to enable preservation of unknown fields, set "preserver_unknown_fields" to true.
Thanks for the help here.