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
