RE: [ft-devel] Regarding GTK/GNOME memory usage optimization

[Turner, David]

Hello again,

well, I'll be answering my own post :-)

I have implemented and commited the improved memory debugger, i.e. the
one that dumps the list of all allocation sites and various statistics
about them. The findings are interesting:

- it is nice, because it's trivial to see what's consuming a lot
  of memory, and what isn't...

- the heap savings in the case of memory-mapped files isn't that
  significant at the moment. We're talking about saving 10KB in a
  90KB usage when loading all glyphs of a font like vera.ttf

- however, it should be possible to attain much greater reduction
  with very little effort. The main idea is to avoid copying tables
  in the heap when we can read them directly from the file.

  I have already commited a few changes to the way the 'loca'
  table is handled (and measured that it had 0 performance impact);
  and we do not load the 'cvt' and 'fpgm' tables anymore when
  the bytecode interpreter isn't compiled in, since these will
  never be loaded. top heap usage in the case described above
  is now down to about 70Kb.

- the next steps will include changing the way other important
  TrueType tables are handled. Mostly metrics, kerning, embedded
  bitmaps and a few others. I hope to gain a few other 10-20 KB,
  depending on the file being used.

- apparently, the auto-hinter is using a _lot_ of memory, especially
  when we load some complex glyphs with 256 points and 63 contours
  (as found in arial.ttf). Moreover, it tends to keep large dynamic
  arrays even if big sizes are only used for one or two glyphs in
  a font.

  it should be possible to reduce the size of dynamic arrays after
  the'yre being used when they exceed a threshold. This is rather
  easy.

  another option is to rewrite the auto-hinter/auto-fitter to
  avoid using pointer-based structures, but used various arrays
  and store 2-byte indices instead of 4-byte pointers. There
  are various ways to optimize storage in it that I won't
  detail here, but this is a rather hard work, so it won't
  begin until we've pruned all other easy elements.


By the way, the current optimizations are controlled by a configuration
macro whose temporary name is "FT_OPTIMIZE_MEMORY" in 'ftoption.h'.

One problem that could happen is that changes to internal FreeType
structures may break rogue libraries that tend to peek at the
internals... this is why I keep the option of disabling the
optimization for the next release.

By the way, maybe it's time for fontconfig and Pango to stop doing
"their thing" and ask for specific APIs instead...

Regards,

- David Turner
- The FreeType Project  (www.freetype.org)


> -----Message d'origine-----
> De : address@hidden
> [mailto:address@hidden 
> la part de
> Turner, David
> Envoyé : mardi 22 février 2005 13:58
> À : address@hidden
> Objet : [ft-devel] Regarding GTK/GNOME memory usage optimization
> 
> 
> Hello everyone,
> 
> I've just read on OSNews about the current effort towards 
> reducing the memory footprint
> of GNOME/GTK+ applications. Though I have very few time, I'd 
> like to offer my help for
> all things related to FreeType (and maybe FontConfig/Pango as well).
> 
> I'm sending this to the FreeType list, because I know that 
> Owen Taylor and Keith Packard
> are subscribers, and likely to read it there.
> 
> Here are random thoughts:
> 
> - FreeType 2 already contains a small memory debugger that 
> can be used to report the
>   maximum and total number of allocations performed by the 
> library on any application.
>   You might find it useful to grab a better understanding of 
> its footprint.
> 
>   Instructions on how to use it are in "docs/DEBUG', that 
> I've joined to this e-mail
>   for simplicity. Basically, you just need to modify one line 
> in 'ftoption.h',
>   recompile, re-install, then use environment variables to 
> trigger the debugger
>   for the applications you want to monitor.
> 
>   the data is generally printed at application's exit, as 
> well as with a list of
>   leaks, when detected. And this works for any application 
> linked to the library.
> 
> - the library handles memory-mapped files gracefully, and is 
> capable of
>   reducing its memory usage accordingly. While there is 
> apparently no performance
>   benefit on platforms like Linux, it may help reduce heap 
> consumption. Moreover,
>   on Windows, reading font files from memory is about 30%-50% 
> faster on Windows,
>   depending on font file size.
> 
>   Note however that it probably is still possible to further 
> reduce heap usage
>   in the presence of memory-mapped files, by taking special 
> actions with various
>   tables and formats. Some of these are easy (in the TrueType 
> loader), others
>   are more complicated (e.g. changing the Type 1 loader to 
> have it perform
>   in-place decyphering and decoding). I hope profiling may 
> give us better
>   directions here.
> 
> - If you think i'd be useful, I can also add some code to 
> provide memory dumps,
>   with the list of all allocation/reallocation sites and the 
> corresponding foot
>   prints. This is generally useful to see what's the memory 
> footprint is after
>   a long period of program execution.
> 
> - It might be possible that some of the drivers exhibit 
> really horrible
>   memory usage. 
> 
> I also think it'd be possible to implement a few tricks to 
> improve the library's
> performance. At least in the context of FontConfig and Pango:
> 
> - opening a new font file can be sped up by loading various 
> tables lazily. This
>   would provide interesting speed-ups for code that only 
> wants to inspect global
>   font data without performing glyph rendering, or retrieving 
> kerning, etc...
> 
> - it is possible to speed-up TrueType charmap enumeration 
> significantly with a
>   bit of additionnal code. It may be useful to speed-up code 
> that scans a charmap
>   to determine Unicode coverage (both in Pango and FontConfig).
> 
> - there's also a small performance hack for the renderers 
> that I still haven't
>   commited. But nothing really fancy (about 5-10% improvements).
> 
> I'll try to grab recent sources for fontconfig and Pango to 
> see if the way FreeType
> is used can be optimized a little...
> 
> Hope this helps,
> 
> - David Turner
> - The FreeType Project  (www.freetype.org)
>