Binary size minimization / optimization

[Nicholas Flink]

Hello I'd like any advice on how I can go about minimizing the size of the binaries generated by ninja, particularly libjingle_peerconnection_so.so which comes in at a whopping 81M.

For my particular project I will not be using video, so my first attempt included commenting out HAVE_WEBRTC_VIDEO in talk/build/common.gypi.  This by itself does not work and yields the following errors.  I'd like to confirm that the desired outcome is that by simply commenting out HAVE_WEBRTC_VIDEO in talk/build/common.gypi the binary should not contain any of the code supporting video. Also I'm interested how NullVideoEngine is supposed to work.  It seems like it should look just like WebRtcVideoEngine but just with placeholders, is that correct?  If there is not already another solution I'll start preparing this patch to share and hopefully integrate.  Finally 81M is pretty huge what have others done to optimize the binary size?

=============INITIAL ERRORS=============

../../talk/app/webrtc/java/jni/peerconnection_jni.cc: In member function '_jobject* (anonymous namespace)::JavaVideoRendererWrapper::CricketToJavaFrame(const cricket::VideoFrame*)':

../../talk/app/webrtc/java/jni/peerconnection_jni.cc:1037:29: error: invalid use of incomplete type 'const struct cricket::VideoFrame'

../../talk/app/webrtc/mediastreaminterface.h:49:7: error: forward declaration of 'const struct cricket::VideoFrame'

...A bunch of others that are the same after wrapping these with HAVE_WEBRTC_VIDEO I get the secondary errors...

===========SECONDARY_ERRORS===========

error: undefined reference to 'cricket::WebRtcVideoEngine::SetLogging(int, char const*)'

error: undefined reference to 'cricket::WebRtcVideoEngine::rtp_header_extensions() const'

...This gets more complicated I'm not 

[Ami Fischman]

Bug 2057 tracks the fact that it's not really possible to exclude video from the webrtc build ATM.

You want to run the .so through strip.  As an example, this invocation of strip reduces a Debug android build of libjingle_peerconnection_so.so from 276M to 3.5M.

(you want to keep the unstripped version around to symbolize stacktraces and so on, but don't need the symbols on the device)

Cheers,

-a

--
 
---
You received this message because you are subscribed to the Google Groups "discuss-webrtc" group.
To unsubscribe from this group and stop receiving emails from it, send an email to discuss-webrt...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

[Nicholas Flink]

Is there a similar thing we can do on ios?  As the android got down to 3.5 I figure the ios should get to roughly the same size, but it is 8.2 on my machine.  

I took a look at the gyp files and didn't see any strip calls called in the ios section.

[Stephen Gutknecht]

The Android one almost seems too small ;) According to my compile today, the Debug one shows stripped

Debug

3592752 bytes

$ file 2013-11-19_debug/armeabi-v7a/libjingle_peerconnection_so.so 

2013-11-19_debug/armeabi-v7a/libjingle_peerconnection_so.so: ELF 32-bit LSB shared object, ARM, version 1 (SYSV), dynamically linked, stripped

Release

3392048 bytes

$ file 2013-11-19_release/armeabi-v7a/libjingle_peerconnection_so.so 

2013-11-19_release/armeabi-v7a/libjingle_peerconnection_so.so: ELF 32-bit LSB shared object, ARM, version 1 (SYSV), dynamically linked, stripped

[Nicholas Flink]

To clarify I can get the java release binary down to ~3.2M or exactly 3387952 bytes.  I've run a strip -u -r on the strip -r -u libjingle_peerconnection.a generates as release for ios, but the smallest I can get it down to is 8.1M or exactly 8509584 bytes.  I mainly concerned the the ios library is more than 2.5 times than the android one even though they contain almost the same code.  

[Nicholas Flink]

Using otool on .../trunk/out_sim/Release/obj/talk/app/webrtc/libjingle_peerconnection.peerconnection.o

It gives lots of information.  Is it safe to strip sections with the attribute DEBUG, and if so does anyone know the correct way to do it?

  sectname __debug_info

   segname __DWARF

      addr 0x00002dfe

      size 0x00025da4

    offset 13458

     align 2^0 (1)

    reloff 473820

    nreloc 2426

      type S_REGULAR

attributes DEBUG

 reserved1 0

 reserved2 0

  sectname __debug_line

   segname __DWARF

      addr 0x00029430

      size 0x00002709

    offset 170692

     align 2^0 (1)

    reloff 493260

    nreloc 2

      type S_REGULAR

attributes DEBUG

Section

  sectname __debug_str

   segname __DWARF

      addr 0x0002fd6a

      size 0x00031754

    offset 197630

     align 2^0 (1)

    reloff 0

    nreloc 0

      type S_REGULAR

attributes DEBUG

 reserved1 0

 reserved2 0

[Ami Fischman]

You don't normally want to strip .o's unless you know what you're doing.

You can see what AppRTCDemo does by looking near the bottom of out_sim/Release/obj/talk/AppRTCDemo.ninja and searching for "strip".

As random data points, the stripped Release build of AppRTCDemo for the simulator is ~15MB, and for iOS device is ~14MB.