Reduce binary size (improve performance?)

[chrisridd]

The fvdi_gnu.prg binary is getting quite large particularly when built with recent versions of Freetype.

Is this a problem at all? Running in Aranym on my fast machine makes it difficult to spot any performance issues, but maybe running on real Atari hardware or Firebee hardware shows issues.

A simple change from compiling with -O2 to -Os (optimise for size) gives some significant savings under gcc 10:

Freetype	-O2	-Os
2.2.1	413798	358708
2.5.2	552936	480038
2.8.1	545559	467904
2.10.2	572271	490336
2.10.3	573797	491053
2.10.4	573793	491045
2.11.0	578391	494679
2.11.1	573511	486117

Moving from Freetype 2.5.2 to 2.11.1 only costs 6KB? That's pretty nice.

Looking at an unstripped binary with nm shows we could save an additional 60KB if we could get rid (somehow!) of some big lists of glyph names, which don't seem to be useful for fVDI as I don't think there's a VDI interface using glyph names:

$ m68k-atari-mint-nm --print-size --size-sort --radix=d fvdi_gnu.prg | tail  
00359748 00001598 t _t1_keywords
00376176 00001804 t _cid_field_records
00338602 00002002 t _cff_field_handlers
00475284 00002050 D default_functions
00490348 00003600 b _spdchar_map
00250144 00003696 T _ft_standard_glyph_names
00466580 00004096 t _fixed_tl
00152906 00005534 T _af_blue_strings
00479548 00008192 b _vdi_stack
00191824 00055998 T _ft_adobe_glyph_list

There are some flags to gcc that help the linker discard unused functions (compile with -ffunction-sections, and link with --gc-sections) but they seem ELF-specific and do not work with the m68k-atari-mint toolchain. No easy win here.

Is this worth pursuing?

[chrisridd]

FWIW removing the "psnames" module from ftconfig.h seems to be enough to get rid of ft_standard_glyph_names and ft_adobe_glyph_list. As far as I can tell this doesn't break anything either; vqt_fontheader() still returns the Postscript font name as before.

I've only tested with Freetype 2.11.1 and with -O2, but it saves 64064 bytes. I've raised PR #29

[mikrosk]

As discussed in #29, not worth the change but thanks for taking time to collect the binary sizes!