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

[Turner, David]

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)

DEBUG
Description: DEBUG