Huge increase of precompiled native libraries for Android and iOS

[Ronny López]

Hi,

We use the experimental Unity package which includes precompiled native libraries Android and iOS.

In the latest versions (concretely while upgrading from version 1.23.x to 1.27.x) , the size of  those precompiled native library has doubled in size.

In Android, from ~20MB to ~42MB

In iOS, from ~90MB to ~208 MB

This makes the package near to unusable in mobile.

Do you folks know what is provoking such huge increase in size?

Thanks 

 

[Jihun Cho]

we have completely different codebase for ios and android. so, it happened on both sides sounds interesting.

i can't speak for the ios part, but for android build we check the binary size, so i am a bit surprised that you experienced this. 

can you narrow down which version caused the binary size increase?

also, can you have some break down other than total binary size?

--
You received this message because you are subscribed to the Google Groups "grpc.io" group.
To unsubscribe from this group and stop receiving emails from it, send an email to grpc-io+u...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/grpc-io/49fb6d80-0c96-439a-a25e-9c89ab06e78f%40googlegroups.com.

[Eric Gribkoff]

+Jan Tattermusch , who (I think) knows more about our Unity builds

To view this discussion on the web visit https://groups.google.com/d/msgid/grpc-io/CABu9GjrFJdr%3DSHiLv_dTVUsSdUSjkC0-x%3D86Yix0pvUOE_eNaA%40mail.gmail.com.

[Nicolas Noble]

I mean... we've been adding a lot of features recently with regards to things like xds, changed nanopb to upb, moved from using C to C++, adding abseil as a dependency, and others. I'm not completely surprised that this would result in a size increase. Similar things have been noted with the python extension for instance, although I'm still not sure if it's a similar problem:  https://github.com/grpc/grpc/issues/21958

Now, sure, it's a fairly massive size increase, but we've gathered more and more dependencies as we're adding new features. That may be the sort of things to expect as you increase the feature set and dependency set.

Getting a linker map of what exactly is in there could be helpful to see if there's really something out of whack, in case there's really something that shouldn't be there, but I'm not necessarily very hopeful in "what we can do" to address this issue in case there isn't anything out of place in the binaries: the monolithic nature of grpc means we can't really "opt out" of these new features.

To view this discussion on the web visit https://groups.google.com/d/msgid/grpc-io/CALUXJ7h5CHA49o2ANLYQmXPQpAw9%2BesNbZarLyZiWPZqEvah-w%40mail.gmail.com.

[Ronny López]

Here you can visually see the increase in size from version 1.23.x to version 1.27.x.

From 93MB to 208MB in iOS. This make this version unusable on low end device and embedded systems. 

Is there anything we can do to help fixing this?

Thanks

1.27

1.23

[Nicolas Noble]

To be useful, this needs to be mapped. Literally the output of the -Map=grpc.map linker option while linking the .so file: https://interrupt.memfault.com/blog/get-the-most-out-of-the-linker-map-file

[Nicolas Noble]

Side-note: these binaries contain debug symbols, per popular request. If you're generating release assets going onto a production package, you'd need to strip the binaries that go there. The libgrpc.a that is 200MB in size probably has about 190MB worth of debugging symbols.

[Nicolas Noble]

I've been doing a cursory inspection of the actual binary, sans debug symbol. Its size grew about about 50% between 2.24 and 2.27, and most of the increase is due to XDS and grpclb being added to the codebase.

[Nicolas Noble]

Correction: I apparently can't do math on a Friday afternoon. It's rather a 20% increase.