Bug 10982 - libfontconfig has large non-constant (unsharable) data arrays
Summary: libfontconfig has large non-constant (unsharable) data arrays
Status: RESOLVED FIXED
Alias: None
Product: fontconfig
Classification: Unclassified
Component: library (show other bugs)
Version: 2.4
Hardware: Other All
: medium normal
Assignee: Keith Packard
QA Contact:
URL:
Whiteboard:
Keywords: patch
Depends on:
Blocks:
 
Reported: 2007-05-17 10:15 UTC by Tilman Sauerbeck
Modified: 2007-10-25 00:39 UTC (History)
1 user (show)

See Also:
i915 platform:
i915 features:


Attachments
0001-Put-language-table-in-read-only-memory.patch (1000 bytes, patch)
2007-05-17 10:15 UTC, Tilman Sauerbeck
Details | Splinter Review
0002-Store-glyph-names-in-read-only-memory.patch (3.47 KB, patch)
2007-05-17 10:16 UTC, Tilman Sauerbeck
Details | Splinter Review
0003-Store-FcCodePageRange-in-read-only-memory.patch (915 bytes, patch)
2007-05-17 10:16 UTC, Tilman Sauerbeck
Details | Splinter Review
0004-Store-FcNoticeFoundries-in-read-only-memory.patch (3.39 KB, patch)
2007-05-17 10:17 UTC, Tilman Sauerbeck
Details | Splinter Review
0005-Store-FcVendorFoundries-in-read-only-memory.patch (3.39 KB, patch)
2007-05-17 10:17 UTC, Tilman Sauerbeck
Details | Splinter Review

Description Tilman Sauerbeck 2007-05-17 10:15:01 UTC
The charset tables etc in libfontconfig aren't constant because they need to be touched at runtime. This leads to a large data section of the binary.

$ size /usr/lib/libfontconfig.so
   text	   data	    bss	    dec	    hex	filename
 138421	  31420	    644	 170485	  299f5	/usr/lib/libfontconfig.so
          ^^^^^

I'll attach a series of patches that trim the data section down to < 3K.
My figures say that saves about 16 KB in every process that loads libfontconfig.
Comment 1 Tilman Sauerbeck 2007-05-17 10:15:46 UTC
Created attachment 10001 [details] [review]
0001-Put-language-table-in-read-only-memory.patch
Comment 2 Tilman Sauerbeck 2007-05-17 10:16:15 UTC
Created attachment 10002 [details] [review]
0002-Store-glyph-names-in-read-only-memory.patch
Comment 3 Tilman Sauerbeck 2007-05-17 10:16:44 UTC
Created attachment 10003 [details] [review]
0003-Store-FcCodePageRange-in-read-only-memory.patch
Comment 4 Tilman Sauerbeck 2007-05-17 10:17:09 UTC
Created attachment 10004 [details] [review]
0004-Store-FcNoticeFoundries-in-read-only-memory.patch
Comment 5 Tilman Sauerbeck 2007-05-17 10:17:25 UTC
Created attachment 10005 [details] [review]
0005-Store-FcVendorFoundries-in-read-only-memory.patch
Comment 6 Huang Peng 2007-08-22 22:06:21 UTC
Below is cut from /proc/PID/smaps of gedit process .

Although data section of the binary image is huge, the Private_Dirty of the data section is only 4kB and most pages of it are shared. The Linux system will not allocate a new page for data section until a page of data section become dirty (be written), and those strings will not be written forever.
So it is not a big problem in Linux. :) (But I don't know other OS how to deal it.:-/ )

4c8c2000-4c8e9000 r-xp 00000000 08:08 1518987    /usr/lib/libfontconfig.so.1.2.0
Size:                156 kB
Rss:                 124 kB
Shared_Clean:        124 kB
Shared_Dirty:          0 kB
Private_Clean:         0 kB
Private_Dirty:         0 kB
Referenced:          124 kB
4c8e9000-4c8f1000 rwxp 00027000 08:08 1518987    /usr/lib/libfontconfig.so.1.2.0
Size:                 32 kB
Rss:                  12 kB
Shared_Clean:          8 kB
Shared_Dirty:          0 kB
Private_Clean:         0 kB
Private_Dirty:         4 kB
Referenced:           12 kB
Comment 7 Keith Packard 2007-10-25 00:39:25 UTC
Thanks; I've pushed all of these changes.


Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.