Dear Sirs, please share with the community ))) How could you strip binaries to size of 800kb?
вторник, 19 сентября 2017 г. в 12:09:40 UTC+3, uttav.a...@gmail.com: > Hi Xuejie Xiao, > Could you please tell how did you reduce the binary size to 800KB. > I have tried to build with strip-static option, and then compiling client > with g++ -s . I am trying to compile the helloworld example. > But the size I am getting is 4.9 MB minimum which is still bigger than > what we require. > Could you please share some info how you have built your client ? > > > On Wednesday, July 22, 2015 at 9:53:40 PM UTC+5:30, Xuejie Xiao wrote: >> >> Nicolas: >> >> Thanks for the detailed explanation! Actually I was being silly here, it >> is indeed the problem of debug symbols. With a single `-s` flag, I can >> strip the binary from around ~ 9M down to ~800K. This is quite reasonable >> for us. >> >> Thanks again for all the help! >> >> On Wed, Jul 22, 2015 at 11:13 PM, Nicolas Noble <pixel...@gmail.com> >> wrote: >> >>> For the server part, the linker will already do what you want, really. >>> If you're not using any of the server function in your binary, with the way >>> gRPC works and is setup, while statically linking, the linker will remove >>> any unused function and the server code will disappear. But the gain should >>> really be negligible. The "server-specific" code I I'm talking about here >>> is but a few lines of code to set up a listener socket, and accepting >>> connections on it. >>> >>> One of the problems of OpenSSL is its registration system, meaning that >>> we're dragging with us an insane amount of unwanted features. It may be >>> possible to shrink down the size of the library by tweaking the compilation >>> of OpenSSL to cull all of the unnecessary parts that the linker can't >>> remove due to the registration. But the current way we're embedding OpenSSL >>> into gRPC is more of a convenience than something that should be used in >>> production. What you really want is to rely on the presence of the OpenSSL >>> dynamic library on your client's machines, and make usage of our NPN >>> fallback mechanism. >>> >>> Basically, remove or rename openssl from third_party (or don't >>> recursively clone the repository). You'll have to make sure you have >>> openssl-dev installed, and you'll have to link with openssl yourself, but >>> then you'll be using the system-wide, well known OpenSSL, hence reducing >>> the size of your binary. >>> >>> As for using another library than OpenSSL, contributions are welcome :-) >>> The relevant code is going to be in src/core/security and src/core/tsi. But >>> this is probably going to be the same issue. In fact, our choice of OpenSSL >>> is only because it's a usually widely installed SSL library, and we don't >>> have to embed it. As I said, we're only embedding it for convenience and >>> test reproducibility. If we were to use another SSL library that we know >>> we'd always embed instead of relying on system-wide libraries, we'd use >>> Google's BoringSSL otherwise :-) >>> >>> Last but not least, if you statically linked, remember to strip your >>> binary. The libraries are compiled with debug symbols in by default, and >>> stripped only during installation, just like any other package. Meaning >>> that if you skip the installation phase, your libraries won't be stripped >>> out of their debugging information, and will drastically bloat your final >>> binary. >>> >>> On Wed, Jul 22, 2015 at 6:26 AM, Xuejie "Rafael" Xiao <xxu...@gmail.com> >>> wrote: >>> >>>> Oops, I must admin that I overlooked the OpenSSL size part in my >>>> previous email, so I *have* to send another email. I just wish we have an >>>> "undo" button for mailing lists :) >>>> >>>> From Nicolas' numbers, it would seem OpenSSL indeed bring a lot of >>>> size. I'm not so familiar with gRPC internals as well as HTTP/2 >>>> encryption, >>>> so please forgive me if this sounds silly: what features are required by >>>> gRPC in a SSL library? You mentioned ALPN support here, so do you think it >>>> will be an easy task to switch to a different SSL library that also has >>>> ALPN support, such as MatrixSSL or mbed TLS? Considering those SSL library >>>> is smaller than OpenSSL, we should expect a smaller binary size, shouldn't >>>> we? >>>> >>>> On Wed, Jul 22, 2015 at 6:49 PM, Xuejie "Rafael" Xiao <xxu...@gmail.com >>>> > wrote: >>>> >>>>> Craig & Nicolas: >>>>> >>>>> Thank you both for your reply! I will use one post to reply to you >>>>> both to save everyone from one extra email :) >>>>> >>>>> I understand that dynamic linking might be able to solve the problem. >>>>> However, we are now thinking of using gRPC as an *external* RPC protocol >>>>> instead of an *internal* one. This means that the client side binary will >>>>> be installed on end user's machine. In this case, I think every byte we >>>>> save will count, and dynamic linking is really not an option for us >>>>> here(user will still have to install gRPC as well as OpenSSL). >>>>> >>>>> Craig: I know this might be too early to tell, but just curious enough >>>>> to ask: how much of the codebase do you think only relate to server hence >>>>> can be stripped from the client? In other words, is there any estimation >>>>> you have on how small the client binary can be, assuming the fact you >>>>> guys >>>>> have the time for this next quarter? >>>>> >>>>> Or maybe we are just using gRPC in the wrong place :P >>>>> >>>>> On Wed, Jul 22, 2015 at 1:14 PM, Nicolas Noble <pixel...@gmail.com> >>>>> wrote: >>>>> >>>>>> Also, it seems that you'd be compiling / linking against the static >>>>>> version of the library ? The grpc shared libraries, once installed, >>>>>> should >>>>>> be considerably smaller, and wouldn't have an impact on your binary size. >>>>>> >>>>>> Right now if I compile grpc, I get the following: >>>>>> >>>>>> $ ls -lah *.so.0.10.0.0 >>>>>> -rwxrwxr-x 1 pixel pixel 51K Jul 22 07:11 libgpr.so.0.10.0.0 >>>>>> -rwxrwxr-x 1 pixel pixel 2.5M Jul 22 07:11 libgrpc.so.0.10.0.0 >>>>>> -rwxrwxr-x 1 pixel pixel 229K Jul 22 07:11 libgrpc++.so.0.10.0.0 >>>>>> -rwxrwxr-x 1 pixel pixel 287K Jul 22 07:11 >>>>>> libgrpc_unsecure.so.0.10.0.0 >>>>>> -rwxrwxr-x 1 pixel pixel 205K Jul 22 07:11 >>>>>> libgrpc++_unsecure.so.0.10.0.0 >>>>>> >>>>>> And this is with OpenSSL embedded. >>>>>> >>>>>> If I remove the embedded OpenSSL, and fallback on NPN, hence using >>>>>> the system's OpenSSL, as Craig mentioned, I get only this: >>>>>> >>>>>> $ ls -lah *.so.0.10.0.0 >>>>>> -rwxrwxr-x 1 pixel pixel 51K Jul 22 07:12 libgpr.so.0.10.0.0 >>>>>> -rwxrwxr-x 1 pixel pixel 405K Jul 22 07:12 libgrpc.so.0.10.0.0 >>>>>> -rwxrwxr-x 1 pixel pixel 229K Jul 22 07:12 libgrpc++.so.0.10.0.0 >>>>>> -rwxrwxr-x 1 pixel pixel 287K Jul 22 07:12 >>>>>> libgrpc_unsecure.so.0.10.0.0 >>>>>> -rwxrwxr-x 1 pixel pixel 205K Jul 22 07:12 >>>>>> libgrpc++_unsecure.so.0.10.0.0 >>>>>> >>>>>> As expected, only the grpc library shrunk down in size, from 2.5M to >>>>>> 405K. >>>>>> >>>>>> So something would seem off with your numbers in all cases. >>>>>> >>>>>> On Tue, Jul 21, 2015 at 7:03 PM, 'Craig Tiller' via grpc.io < >>>>>> grp...@googlegroups.com> wrote: >>>>>> >>>>>>> Hey! >>>>>>> >>>>>>> We haven't spent a huge amount of time optimizing for size, but I >>>>>>> expect to do some work in that direction in the coming quarter (or so). >>>>>>> >>>>>>> That said, most of our code base is relatively symmetric, so I don't >>>>>>> expect to see massive differences in client and servers for the greeter >>>>>>> example. >>>>>>> >>>>>>> Most of the existing cost is OpenSSL I expect. If you can rely on >>>>>>> the system library (and therefore don't mind using npn instead of alpn) >>>>>>> - >>>>>>> or if you don't need crypto and auth - then that cost goes way down. >>>>>>> >>>>>>> If you do need alpn (its required by http2, so as soon as you need >>>>>>> ssl and don't control all intermediaries you may), then that cost is >>>>>>> going >>>>>>> to be there. You might be able to amortize that cost if any other >>>>>>> library >>>>>>> you're considering also needs to link a recentish OpenSSL. >>>>>>> >>>>>>> On Tue, Jul 21, 2015, 6:11 PM Xuejie Xiao <xxu...@gmail.com> wrote: >>>>>>> >>>>>>>> Hey guys! >>>>>>>> >>>>>>>> We are evaluating gRPC internally, one thing we've found out, is >>>>>>>> that the compile C++ binary size is quite big, this is even the case >>>>>>>> for >>>>>>>> client binaries. For example, if we compile the C++ helloworld example >>>>>>>> from >>>>>>>> grpc-common repo, greeter_client will be 9.4M, while greeter_server is >>>>>>>> 9.5M. >>>>>>>> >>>>>>>> So our question here is: is it true that the client-side binary >>>>>>>> requires almost the same binary size as the server-side binary? Is it >>>>>>>> possible to strip the client binary size here? >>>>>>>> >>>>>>>> Or maybe we are actually using a wrong linking argument here? >>>>>>>> >>>>>>>> Many thanks! >>>>>>>> >>>>>>>> -- >>>>>>>> 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 post to this group, send email to grp...@googlegroups.com. >>>>>>>> To view this discussion on the web visit >>>>>>>> https://groups.google.com/d/msgid/grpc-io/47b360e7-8332-449d-b444-060ec98c45ab%40googlegroups.com >>>>>>>> >>>>>>>> <https://groups.google.com/d/msgid/grpc-io/47b360e7-8332-449d-b444-060ec98c45ab%40googlegroups.com?utm_medium=email&utm_source=footer> >>>>>>>> . >>>>>>>> For more options, visit https://groups.google.com/d/optout. >>>>>>>> >>>>>>> -- >>>>>>> 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 post to this group, send email to grp...@googlegroups.com. >>>>>>> To view this discussion on the web visit >>>>>>> https://groups.google.com/d/msgid/grpc-io/CAAvp3oNkLi9iAuajBcrogJddk_AoTLUetDncs857w55tG8qhHw%40mail.gmail.com >>>>>>> >>>>>>> <https://groups.google.com/d/msgid/grpc-io/CAAvp3oNkLi9iAuajBcrogJddk_AoTLUetDncs857w55tG8qhHw%40mail.gmail.com?utm_medium=email&utm_source=footer> >>>>>>> . >>>>>>> >>>>>>> For more options, visit https://groups.google.com/d/optout. >>>>>>> >>>>>> >>>>>> >>>>> >>>>> >>>>> -- >>>>> Best Regards, >>>>> >>>>> Xuejie "Rafael" Xiao >>>>> >>>>> >>>> >>>> >>>> -- >>>> Best Regards, >>>> >>>> Xuejie "Rafael" Xiao >>>> >>>> >>> >> >> >> -- >> Best Regards, >> >> Xuejie "Rafael" Xiao >> >> -- 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+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/grpc-io/7c44e103-3a9f-42d2-91cf-95330715e9b3n%40googlegroups.com.
