[Fontconfig] Application startup performance
Behdad Esfahbod
behdad at behdad.org
Sun Mar 13 20:40:41 UTC 2016
Thanks Raimund for looking into this!
There are four usecases we need to consider:
- Normal Linux / other Unix-like. We can assume high-precision
timestamps are available and take care of stuff,
- Linux / Unix-like system with network file system. Any issues there
with your proposed patch?
- Linux / Unix-like system with FAT or other low-precision timestamp file
system. Do we care much about that? I believe we've fixed bugs for those
systems before. I just am not sure how much we care about small races
there.
- Windows. I'm fine with leaving some known races there alone.
behdad
On Sun, Mar 13, 2016 at 1:12 PM, Raimund Steger <rs at mytum.de> wrote:
> On Fri, 11 Mar 2016 19:16:57 +0900
> Akira TAGOH <akira at tagoh.org> wrote:
>
> > f44bfad2 could be reverted perhaps but need to test carefully before
> > doing that. unfortunately I don't have a time to do that so far.
>
> I think that might be a good idea. I've now read the linked Fedora bug
> again [1] and as far as I understand (with only little insight in Fedora's
> history with this problem):
>
> The race condition surfaced when installing urw-fonts as part of an
> enblend (or similar tools, in terms of dependencies) build, in that the
> .../Type1 directory cache somehow had an inadequate timestamp after
> postinstall. This was attributed to parallel invocations of fontconfig's
> caching routines.
>
> Now I've looked at the dependencies of enblend. Indeed I see some stuff
> that might pull other fonts in, for example gnuplot which depends on DejaVu
> fonts. Nowadays this probably doesn't take too long so all of it could
> really take place within seconds.
>
> I've also downloaded the attached test case and linked it with
> fontconfig-2.9.0, 2.10.0, and 2.11.9x (current Git). Indeed, with all
> earlier versions (than 2.11.9x) I can see the problem; the file 01.pcf,
> which is added while the other stuff is scanned, isn't picked up.
>
> However, if I check the mtimes in /tmp I see that everything happens in
> the same second:
>
>
> sun2:fontconfig)ls -E /tmp/fcbz69845-fonts-XXgyaO2j
> total 216
> drwxr-xr-x 2 rs rs01 179 2016-03-13 20:42:25.286523696
> +0100 0/
> drwxr-xr-x 2 rs rs01 180 2016-03-13 20:42:25.331396817
> +0100 01/
> drwxr-xr-x 2 rs rs01 179 2016-03-13 20:42:25.286844908
> +0100 1/
> drwxr-xr-x 2 rs rs01 180 2016-03-13 20:42:25.288598316
> +0100 10/
> drwxr-xr-x 2 rs rs01 180 2016-03-13 20:42:25.288793584
> +0100 11/
> drwxr-xr-x 2 rs rs01 180 2016-03-13 20:42:25.288986704
> +0100 12/
> drwxr-xr-x 2 rs rs01 180 2016-03-13 20:42:25.289179054
> +0100 13/
> drwxr-xr-x 2 rs rs01 180 2016-03-13 20:42:25.289372500
> +0100 14/
> drwxr-xr-x 2 rs rs01 180 2016-03-13 20:42:25.289566288
> +0100 15/
> drwxr-xr-x 2 rs rs01 180 2016-03-13 20:42:25.289756148
> +0100 16/
> drwxr-xr-x 2 rs rs01 180 2016-03-13 20:42:25.289947012
> +0100 17/
> drwxr-xr-x 2 rs rs01 180 2016-03-13 20:42:25.290156261
> +0100 18/
> drwxr-xr-x 2 rs rs01 180 2016-03-13 20:42:25.290349106
> +0100 19/
> drwxr-xr-x 2 rs rs01 179 2016-03-13 20:42:25.287043469
> +0100 2/
> drwxr-xr-x 2 rs rs01 180 2016-03-13 20:42:25.290539282
> +0100 20/
> drwxr-xr-x 2 rs rs01 180 2016-03-13 20:42:25.290731146
> +0100 21/
> drwxr-xr-x 2 rs rs01 180 2016-03-13 20:42:25.290920807
> +0100 22/
> drwxr-xr-x 2 rs rs01 180 2016-03-13 20:42:25.291111970
> +0100 23/
> drwxr-xr-x 2 rs rs01 180 2016-03-13 20:42:25.291304851
> +0100 24/
> drwxr-xr-x 2 rs rs01 180 2016-03-13 20:42:25.291496406
> +0100 25/
> drwxr-xr-x 2 rs rs01 179 2016-03-13 20:42:25.287238447
> +0100 3/
> drwxr-xr-x 2 rs rs01 179 2016-03-13 20:42:25.287432511
> +0100 4/
> drwxr-xr-x 2 rs rs01 179 2016-03-13 20:42:25.287626802
> +0100 5/
> drwxr-xr-x 2 rs rs01 179 2016-03-13 20:42:25.287820816
> +0100 6/
> drwxr-xr-x 2 rs rs01 179 2016-03-13 20:42:25.288018928
> +0100 7/
> drwxr-xr-x 2 rs rs01 179 2016-03-13 20:42:25.288210736
> +0100 8/
> drwxr-xr-x 2 rs rs01 179 2016-03-13 20:42:25.288402321
> +0100 9/
>
>
> I then tried to revert f44bfad2 and also the FcDirCacheLock/Unlock part of
> ad9f5880502c9a3f8e7f8919336888ee056f17ba (attached) and tried the test
> again. The latter is because I have the feeling it's not strictly required
> either. The cache files have their individual locking and even if the dir
> isn't locked, as Keith argued (and I can find no flaw there) any later
> fc-cache /will/ pick the stuff up.
>
> Now I see that whenever I also remove the nanosecond stuff, the test
> fails. When I leave it in, it works.
>
> Of course that's no extensive testing or anything. But it might just be
> that the finer mtime is now good enough.
>
> Raimund
>
>
>
> [1] https://bugzilla.redhat.com/show_bug.cgi?id=921706
>
>
>
>
>
>
>
> >
> > On Fri, Mar 11, 2016 at 8:26 AM, Behdad Esfahbod <behdad at behdad.org>
> wrote:
> > > Any resolution here? Current master's behavior of stating all fonts is
> > > definitely very bad. Anyone volunteer to clean up the cache code a
> bit?
> > >
> > > On Mon, Jan 18, 2016 at 7:09 PM, Akira TAGOH <akira at tagoh.org> wrote:
> > >>
> > >> On Mon, Jan 18, 2016 at 5:54 PM, Keith Packard <keithp at keithp.com>
> wrote:
> > >> > Akira TAGOH <akira at tagoh.org> writes:
> > >> >
> > >> >> Not exactly. fontconfig doesn't stat everey directory at runtime
> but
> > >> >> relies on the subdir list in the cache to traverse. so if it isn't
> > >> >> outdated and missing some, it won't be picked up by fontconfig.
> > >> >
> > >> > How can it "miss some" if it checks the timestamp of the parent
> before
> > >> > relying on the list?
> > >>
> > >> Previously fontconfig only locks the file when writing out. the time
> > >> to write it out since bringing up fc-cache depends on the time of
> > >> collecting data and it takes more time if there are more targeted
> > >> files and directories. and likely to see a process finished first
> > >> which brought up later.
> > >> so I locked out between reading and writing to avoid it.
> > >>
> > >> >> Not sure but perhaps it is. my memory is already vague and not
> sure if
> > >> >> it had a nano second in the mtime. so better testing anyway.
> > >> >
> > >> > Hrm. Is fontconfig even using the higher resolution time when the
> file
> > >> > system supports it?
> > >>
> > >> Yes. well, very recently. not yet included in any releases.
> > >>
> > >> --
> > >> Akira TAGOH
> > >> _______________________________________________
> > >> Fontconfig mailing list
> > >> Fontconfig at lists.freedesktop.org
> > >> http://lists.freedesktop.org/mailman/listinfo/fontconfig
> > >
> > >
> > >
> > >
> > > --
> > > behdad
> > > http://behdad.org/
> >
> >
> >
> > --
> > Akira TAGOH
> > _______________________________________________
> > Fontconfig mailing list
> > Fontconfig at lists.freedesktop.org
> > https://lists.freedesktop.org/mailman/listinfo/fontconfig
>
>
> --
> Worringer Str 31 Duesseldorf 40211 DE home: rs at mytum.de
> +49-179-2981632 icq 16845346 work: rs at interface-ag.de
>
--
behdad
http://behdad.org/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/fontconfig/attachments/20160313/3e75d604/attachment-0001.html>
More information about the Fontconfig
mailing list