[patch]: mmapping FontConfig data structures

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



This patch:

http://plam.csail.mit.edu/~plam/tmp/fontconfig-mmap-050609.diff

modifies fontconfig's CVS HEAD to use an mmap()able file
containing internal fontconfig data structures.  The new binary
fc-mmap creates this map file (in /tmp, for now[1]) and fontconfig
clients use this map file instead of loading font data themselves.

On my system, my modified version of fontconfig mmaps 147786 bytes
into memory (instead of creating around 100k of dynamic data
structures).  I believe that this patch is stable; it produces no
differences in behaviour as compared to a stock fontconfig under
my tests.

The public API modified the patch is a pair of functions,
FcMmapForce() and FcMmapSave().  FcMmapForce(true) forces fontconfig
to ignore any mmaping data which might exist, and FcMmapSave() is used
in fc-mmap to write the data structures to disk.  Unlike an earlier version
of the patch, no other API modifications are necessary.

The structure of the patch is as follows.

1. Loading: I include a new file, src/fcmmap.c, which contains the
bulk of the logic for reading and writing the mmap file; some logic
lives in src/fclang.c (to serialize a data structure private to that
file).  During fontconfig's initialization, it first calls
FcMmapLoadObjects immediately after opening the configuration file,
but before processing it, to load string constants into memory.  Later
on, fontconfig calls FcMmapLoadFonts to mmap the rest of the mmapped
data into memory, instead of loading the data from the font files.

2. Saving: I use a three-phase algorithm to save the data to disk.  In
the first phase (initiated by FcMmapSave's call to
FcFontSetSerialize(config)), I move all font information reachable
from currentConfig.fonts to a set of static arrays (with a first
relocation from the dynamic addresses to the static arrays).  Next, I
write the data to the candidate mmap file.  The final phase is the
fixup; I use mmap() to read the data back into memory, recording the
addresses given to me by mmap() to, again, relocate internal pointers
as appropriate.  Once fixup is complete, the mmap file is ready to be
loaded with no further transformations.

Thanks to Sylvain Fourmanoit for hints on how to improve an earlier
version of this patch.

I would like this patch to be considered for inclusion in the fontconfig
CVS.

pat

[1] I would appreciate any suggestions on where the map file should be
created.  It is difficult to put the map file's location in the
configuration file, because the map file is needed before fontconfig
loads the configuration information.

[Index of Archives]     [Fedora Fonts]     [Fedora Users]     [Fedora Cloud]     [Kernel]     [Fedora Packaging]     [Fedora Desktop]     [PAM]     [Gimp Graphics Editor]     [Yosemite News]

  Powered by Linux