[Fontconfig] Re: [patch]: serialize fontconfig data structures

[Keith Packard]

On Mon, 2005-06-13 at 23:26 -0400, Patrick Lam wrote:

> One thing that I might want to look into is eliminating duplication e.g.
> of FcLangSet and FcCharSet objects, for instance by canonicalizing them
> in a hash table or something.  Such a change would save space (which is
> now mmapped, but still.)

FcLangSet is a bitmap with one bit per supported language, or 183 bits
per font.  This may not be worth the effort to share.  FcCharSets were
shared in the past, but that sharing is global across all fonts read
into the system.  The data structures shared individual 'pages' and then
(occasionally) entire collections of pages.  As identifying the
codepoints supported by every font is a common part of the matching
operation, having fewer pages referenced by the fonts would be a really
good thing.

> Another note is that the current version of fontconfig uses string
> addresses to compare and sort strings.  My patch computes hash codes
> instead of using string addresses, which are hard to use as a portable
> hash code

Hmm.  The use of string addresses was a result of some extensive
profiling done for fontconfig that showed string compares taking an
inordinate amount of time.  Many of these are for the element names, for
which a pointer comparison is awfully nice.  Given that all of the
elements in the cache files must be generated by fontconfig, we should
consider replacing the 'char *' in the elements with an integer indexing
a static table of names.  Sort that table and we can even do binary
searches within the patterns on just the integers.  Element names which
aren't one of the standard names can be allocated from a separate pool
of values and used to index a table and compared using regular string
comparison functions.

For other strings, most comparisons must be done in a case-insensitive
fashion, and aren't 'ordered', so a hash function which was computed in
a case insensitive fashion would actually be a huge advantage (hash not
match => strings not match).

> The remaining work is pretty simple; I just need to write fc-mmap.c using
> this new API, satisfying all of keithp's constraints.

I don't think we need another application; fc-cache should be able to
create the cache files using the existing library code.  We will then
deprecate the -1 version cache files and use only the -2 versions.

Are there any architecture dependencies in the cache file organization?
If so, we'll want to provide for multiple architectures in the same
cache file.

> Please commit this patch.

I'm excited to see this come together so quickly; I'd like to see some
code review before the patch lands, if there are others on the list with
the ability to help out there, it would be greatly appreciated.  I'll
review the actual code soon, but more eyes are always better.

-keith

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
Url : http://lists.freedesktop.org/archives/fontconfig/attachments/20050613/b09deb53/attachment.pgp