Hi, I am investigating why FcFontSetSort is allocating and freeing data around 100000 times. So I first removed the main malloc inside FcFontSetSort, but that''s really not the main source of allocation. In fact all the allocation is done inside FcSortWalk and freeing is done by FcCharSetDestroy, when I am calling FcFontSetSort with csp == NULL and trim == FcTrue. And looking inside FcSortWalk, when trim =FcTrue, FcCharSet will be created. It''s the first time I look at FontConfig source code, and my understanding of its code is quite limited, so does someone know why it is needed to create this FcCharSet, as it seems to me that we allocate/populate just to destroy them. Isn''t it possible to change in file src/fcmatch.c at line 602, the test "if (trim || build_cs)" by just "if (build_cs)" and remove all this allocation ? Regards, -- Cedric BAIL -------------- next part -------------- A non-text attachment was scrubbed... Name: fontconfig-one-less-malloc.diff Type: text/x-diff Size: 1512 bytes Desc: not available Url : http://lists.freedesktop.org/archives/fontconfig/attachments/20090615/e82deea7/attachment.diff
Did you try my tree? That will become fontconfig 2.7 soon (as soon as I can get away from happenings in Iran and back to work :(( ) http://mces.blogspot.com/2009/06/if-you-see-keith-packard-say-hello.html b On 06/15/2009 05:43 AM, Cedric BAIL wrote:> Hi, > > I am investigating why FcFontSetSort is allocating and freeing data > around 100000 times. So I first removed the main malloc inside > FcFontSetSort, but that''s really not the main source of allocation. In > fact all the allocation is done inside FcSortWalk and freeing is done > by FcCharSetDestroy, when I am calling FcFontSetSort with csp == NULL > and trim == FcTrue. And looking inside FcSortWalk, when trim => FcTrue, FcCharSet will be created. > It''s the first time I look at FontConfig source code, and my > understanding of its code is quite limited, so does someone know why > it is needed to create this FcCharSet, as it seems to me that we > allocate/populate just to destroy them. Isn''t it possible to change in > file src/fcmatch.c at line 602, the test "if (trim || build_cs)" by > just "if (build_cs)" and remove all this allocation ? > > Regards, > > > ------------------------------------------------------------------------ > > _______________________________________________ > Fontconfig mailing list > Fontconfig at lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/fontconfig
On Mon, Jun 15, 2009 at 12:47 PM, Behdad Esfahbod<behdad at behdad.org> wrote:> Did you try my tree? ?That will become fontconfig 2.7 soon (as soon as I can > get away from happenings in Iran and back to work :(( ) > > http://mces.blogspot.com/2009/06/if-you-see-keith-packard-say-hello.htmlNow, I did, and yes it work much better regarding my test case. Thanks a lot for pointing me this tree. Regards, -- Cedric BAIL
Behdad Esfahbod
2009-Jun-15 13:39 UTC
[Fontconfig] Before you release 2.7 (Was: Reducing allocation in FcFontSetSort)
I''m mostly interesting in 2.6 vs 2.7 regressions. But yeah, tracking down helps. On 06/15/2009 09:36 AM, Jan Slupski wrote:> On 06/15/09 12:47, Behdad Esfahbod wrote: >> Did you try my tree? That will become fontconfig 2.7 soon > > Before you release 2.7 - do you want me to investigate anything more on > the 2.7 vs 2.4.2 crash issue, or such changes in the cache are just > "by design" and needs to be addressed at the users side? > > http://lists.freedesktop.org/archives/fontconfig/2009-June/003168.html > > Thanks, > Jan >