locked
Insane binary size when creating an ARMv7/ARMv7s/ARM64 App RRS feed

  • Question

  • User32853 posted

    Hi there,

    I noticed, that the app binary gains an insane size, when you build an app with all three currently available archtictures (ARMv7, ARMv7s, ARM64), while I ported the MonoGame iOS Version to the new unified API.

    Here are some numbers:

    ARMv7 
    9,9 MB (9.922.752 Byte)
    
    ARMv7s
    10,0 MB (9.955.712 Byte)
    
    ARM64
    10,9 MB (10.940.576 Byte)
    
    All
    80,0 MB (79.985.792 Byte)
    

    First, I build a test app using MonoGame only for a specific architecture, those binaries are about 10 MB each. If I build the same app for all three architectures, it goes up to 80 MB for no reason.

    Is this some kind of bug or am I missing something?

    Monday, October 27, 2014 7:11 PM

All replies

  • User32853 posted

    I just made a test with a native app, using the AdMob SDK. Here are the file sizes for the binary:

    ARMv7
    1.367.136 Byte (1,4 MB)
    
    ARMv7s
    1.367.216 Byte (1,4 MB)
    
    ARM64
    1.460.960 Byte (1,5 MB)
    
    All
    4.229.856 Byte (4,2 MB)
    

    This looks more realistic and makes sense.

    otool also outputs the correct sizes:

    xcrun -sdk iphoneos otool -h -f -a BannerExample
    Fat headers
    fat_magic 0xcafebabe
    nfat_arch 3
    architecture 0
        cputype 12
        cpusubtype 9
        capabilities 0x0
        offset 16384
        size 1367216
        align 2^14 (16384)
    architecture 1
        cputype 12
        cpusubtype 11
        capabilities 0x0
        offset 1392640
        size 1367136
        align 2^14 (16384)
    architecture 2
        cputype 16777228
        cpusubtype 0
        capabilities 0x0
        offset 2768896
        size 1460960
        align 2^14 (16384)
    BannerExample (architecture armv7):
    Mach header
          magic cputype cpusubtype  caps    filetype ncmds sizeofcmds      flags
     0xfeedface      12          9  0x00          2    31       3884 0x00200085
    BannerExample (architecture armv7s):
    Mach header
          magic cputype cpusubtype  caps    filetype ncmds sizeofcmds      flags
     0xfeedface      12         11  0x00          2    31       3884 0x00200085
    BannerExample (architecture arm64):
    Mach header
          magic cputype cpusubtype  caps    filetype ncmds sizeofcmds      flags
     0xfeedfacf 16777228          0  0x00          2    33       4232 0x00200085
    

    This is what otool outputs for the binary of the first post, you can see that the binary sizes don't match at all:

    xcrun -sdk iphoneos otool -h -f -a BionickSheepiOS 
    Fat headers
    fat_magic 0xcafebabe
    nfat_arch 3
    architecture 0
        cputype 12
        cpusubtype 9
        capabilities 0x0
        offset 16384
        size 25743472
        align 2^14 (16384)
    architecture 1
        cputype 12
        cpusubtype 11
        capabilities 0x0
        offset 25772032
        size 25769600
        align 2^14 (16384)
    architecture 2
        cputype 16777228
        cpusubtype 0
        capabilities 0x0
        offset 51544064
        size 28441728
        align 2^14 (16384)
    BionickSheepiOS (architecture armv7):
    Mach header
          magic cputype cpusubtype  caps    filetype ncmds sizeofcmds      flags
     0xfeedface      12          9  0x00          2    42       4436 0x00200085
    BionickSheepiOS (architecture armv7s):
    Mach header
          magic cputype cpusubtype  caps    filetype ncmds sizeofcmds      flags
     0xfeedface      12         11  0x00          2    42       4436 0x00200085
    BionickSheepiOS (architecture arm64):
    Mach header
          magic cputype cpusubtype  caps    filetype ncmds sizeofcmds      flags
     0xfeedfacf 16777228          0  0x00          2    42       5064 0x00200085
    

    So, this must be a bug in Xamarin, that the final binary is more then two times the size of the sum of all architectures.

    Tuesday, October 28, 2014 10:29 AM
  • User2589 posted

    You can roughly expect a FAT application to be X times bigger than a single arch, where X is the number of architectures, i.e. a 15MB ARMv7 app would be around 45MB for ARMv7+ARMv7s+ARM64 - the later arch being a bit larger.

    In fact it should be nearly identical to the sum of individual executables as there's not really anything to gain / share across them (except that ARMv7 and ARMv7s can share the same assemblies for metadata).

    If that's not the case then something is wrong. I'll try to duplicate the issue you filed. It's possible a wrong setting (e.g. debug) is being used - and that would affect the binary size.

    Wednesday, October 29, 2014 1:26 AM
  • User2589 posted

    It turns out that the post-lipoed, thin, executables were stripped. A 32/64bits FAT application needs to be stripped later (after lipo). That's different from our 32/32 (e.g. ARMv7+ARMv7s) builds.

    Thanks for your report!

    Wednesday, October 29, 2014 1:39 PM
  • User32853 posted

    Thanks a lot, Sebastien.

    Wednesday, October 29, 2014 5:59 PM