Squashing the beast into a 60MB cage Tor Lillqvist - - PowerPoint PPT Presentation

▶
squashing the beast into a 60mb cage
SMART_READER_LITE
LIVE PREVIEW

Squashing the beast into a 60MB cage Tor Lillqvist - - PowerPoint PPT Presentation

Jul 19, 2023 329 likes •817 views

Squashing the beast into a 60MB cage Tor Lillqvist <tml@collabora.com> tml, #libreoffice-dev, irc.freenode.net Background: One single executable in an iOS app. No own shared libs Repeat: all non-system code has to be in one executable

slide-1
SLIDE 1

Squashing the beast into a 60MB cage

Tor Lillqvist <tml@collabora.com> tml, #libreoffice-dev, irc.freenode.net

slide-2
SLIDE 2

Background: One single executable in an iOS

  • app. No own shared libs
slide-3
SLIDE 3

Repeat: all non-system code has to be in one executable

slide-4
SLIDE 4

App Store rules: “iOS App binary files can be as large as 2 GB”

slide-5
SLIDE 5

“but”

slide-6
SLIDE 6

“the executable file cannot exceed 60 MB”

slide-7
SLIDE 7

We have one test iOS app: TiledLibreOffice

slide-8
SLIDE 8

(which is a simple viewer for Writer docs)

slide-9
SLIDE 9

At first, the TiledLibreOffice executable was ~90MB

slide-10
SLIDE 10

(optimised build, no debug information or symbols in the file)

slide-11
SLIDE 11

A third had to go without loss of functionality

slide-12
SLIDE 12

Obviously there is a lot

  • f code that gets linked

in but never will get called at run-time

slide-13
SLIDE 13

But we don't want to sprinkle ugly ifdefs all

  • ver the place if we don't

have to

slide-14
SLIDE 14

Only in as few key places as possible

slide-15
SLIDE 15

Largest code reduction: ICU data

slide-16
SLIDE 16

(“Internationalisation Components for Unicode”)

slide-17
SLIDE 17

Normally, ICU data is present as constant data in code segment

slide-18
SLIDE 18

When building ICU one has the option to use a data file instead

slide-19
SLIDE 19

This data file needs to be memory-mapped in and passed to a single ICU call

slide-20
SLIDE 20

Saving from ICU data:

  • 23MB. Still lots to go
slide-21
SLIDE 21

Locale data tables

slide-22
SLIDE 22

Desktop LibreOffice includes data for all locales we know of

slide-23
SLIDE 23

… but no need to do that in an iOS app

slide-24
SLIDE 24

Introduce --with-locales configure-time option

slide-25
SLIDE 25

Restricts what locales have data compiled in

slide-26
SLIDE 26

Even better would be to use data files instead of constant data in code

slide-27
SLIDE 27

… but that can be complicated

slide-28
SLIDE 28

Our Japanese and Chinese “dictionaries” are large

slide-29
SLIDE 29

Luckily simply structured, so can use memory- mapped data files instead

slide-30
SLIDE 30

Use generated data files instead of generated code for OOXML custom shape presets

slide-31
SLIDE 31

Split UNO components into smaller ones by refactoring factory methods

slide-32
SLIDE 32

More aggressive ifdeffing-out of code irrelevant on mobile platforms

slide-33
SLIDE 33

(for instance: to bypass code for desktop-style help, a11y features or extensions)

slide-34
SLIDE 34

Charset/encoding conversion tables in sal: Optionally bin obscure

  • nes
slide-35
SLIDE 35

Tell compiler to optimise harder: -Oz

slide-36
SLIDE 36

Unfortunately, somewhat fragile, compiler bugs?

slide-37
SLIDE 37

Link-time optimisation? Not feasible: Linker grew to 40 GB in one hour before I lost patience

slide-38
SLIDE 38

Non-issue: Unreferenced

  • functions. Linker is

smart, we use

  • dead_strip
slide-39
SLIDE 39

Note: Don't make assumptions based on Linux experience

slide-40
SLIDE 40

Apple's object file format, executable file format, and toolchain are different

slide-41
SLIDE 41

How to find stuff to get rid of?

slide-42
SLIDE 42

Inspect the linker map, workdir/ TiledLibreOffice.map

slide-43
SLIDE 43

Use the bin/ios-mapfile- statistics script

slide-44
SLIDE 44

Oh, and after the squashing spree, the size of TiledLibreOffice was 43MB

slide-45
SLIDE 45

Thanks to CloudOn for funding this work

slide-46
SLIDE 46

FIN

slide-47
SLIDE 47

Collabora

  • Collabora Ltd.

– Leading Open Source Consultancy – 8 years of experience. 90+ People.

  • Collabora Productivity Ltd.

– Dedicated to Enterprise LibreOffice – Provides Level-3 support (code issues) to all

Novell / SUSE LibreOffice clients

– Architects of Microsoft OpenXML filters