grpc-xds pulls in 20MiB of envoy proxy config protobuf bindings

[hanikesn]

What version of gRPC-Java are you using?

1.45.1

What is your environment?

What did you expect to see?

Less resource usage as grpc-xds is a library with wide-spread use.

What did you see instead?

grpc-xds jar using 11.8MiB of compress space

Steps to reproduce the bug

https://mvnrepository.com/artifact/io.grpc/grpc-xds/1.48.1

[sanjaypujare]

These bindings are required when xds is used even if certain classes are not used in certain situations (e.g. server side config protos when the application is just a client application). What suggestions do you have to optimize the size while preserving the functionality?

[hanikesn]

I'm specifically talking about e.g. /io/grpc/xds/shaded/io/envoyproxy/envoy/config/, which uses 16MiB alone uncompressed. If these classes are critical for the operation it might make sense to split the grpc-xds package even further.

[sanjaypujare]

... might make sense to split the grpc-xds package even further.

Could you elaborate on the split? Split along which lines?

[hanikesn]

I'm sorry I'm not intrinsically familiar with xds or grpc-xds, I just see this package being pulled in by various google cloud sdk libraries and it increases the size of our jars significantly and it doesn't seem like all the classes from envoy are actually used by grpc-xds

[ejona86]

xDS has a semi-monolithic set of messages. We're only generated code for files that we need messages, but it trivially causes a cascade as a message may have a field that we don't use but the type of that field still has to be built and included as well, transitively. If those fields aren't ever set, then those classes won't be loaded at runtime. But the server chooses which fields are set.

gax-java could potentially avoid the dependency for services not using xds, but commonly-used and high performance services are more likely to be using xds as it provides those services with the greatest gains.