all messages for Guix-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
From: Sarah Morgensen via Guix-patches via <guix-patches@gnu.org>
To: "Ludovic Courtès" <ludo@gnu.org>
Cc: 49107@debbugs.gnu.org
Subject: [bug#49107] [PATCH core-updates] gnu: fontconfig: Use (locally) deterministic caching
Date: Wed, 07 Jul 2021 18:17:30 -0700	[thread overview]
Message-ID: <86eec9k3it.fsf_-_@mgsn.dev> (raw)
In-Reply-To: <87sg0pomee.fsf@gnu.org> ("Ludovic Courtès"'s message of "Wed, 07 Jul 2021 23:16:09 +0200")

Hello,

Thanks for taking a look at this.

Ludovic Courtès <ludo@gnu.org> writes:

>> Fontconfig usually uses a directory's mtime as its checksum. However, when
>> fontconfig detects a "broken mtime" filesystem, it will generate a directory
>> checksum from the directory listing contents. This is slightly slower, as it has
>> to stat all the files in all font directories. Unconditionally enabling this
>> mode should get us more regular behavior.
>
> Nice, sounds like an improvement!
>
> Does Fontconfig stats all these files every time an application starts?
> Did you compare ‘strace -c some app’ with and without this change, to
> get an idea of what it costs?

I *believe* it does so whenever an application calls FcFontList or such,
which is usually on startup. I haven't done tracing with an application
that actually uses FcFontList, but I just now ran a naive test, along
the lines of:

  $ fc-cache -rf
  $ strace -c fc-list

The old fc-list:

--8<---------------cut here---------------start------------->8---
% time     seconds  usecs/call     calls    errors syscall
------ ----------- ----------- --------- --------- ----------------
 28.50    0.000226           0       228       142 openat
 22.19    0.000176           1       136        26 access
 11.10    0.000088           0       133        70 stat
  5.93    0.000047           0        86           close
  5.55    0.000044           2        22           fstatfs
  5.30    0.000042           0        54        37 readlink
  4.54    0.000036           4         8           munmap
  3.78    0.000030           0        70           mmap
  2.65    0.000021           1        20           write
  2.52    0.000020           0       104           read
  2.52    0.000020           0        40           fstat
  1.89    0.000015           1         8           fadvise64
  1.77    0.000014           1        10           getpid
  0.88    0.000007           0        10           brk
  0.63    0.000005           0        35           getrandom
  0.25    0.000002           2         1         1 ioctl
  0.00    0.000000           0        15           mprotect
  0.00    0.000000           0         2           rt_sigaction
  0.00    0.000000           0         1           rt_sigprocmask
  0.00    0.000000           0         1           execve
  0.00    0.000000           0         1           arch_prctl
  0.00    0.000000           0         1           futex
  0.00    0.000000           0         4           getdents64
  0.00    0.000000           0         1           set_tid_address
  0.00    0.000000           0         1           set_robust_list
  0.00    0.000000           0         1           prlimit64
------ ----------- ----------- --------- --------- ----------------
100.00    0.000793           0       993       276 total
--8<---------------cut here---------------end--------------->8---

And the patched fc-list:

--8<---------------cut here---------------start------------->8---
% time     seconds  usecs/call     calls    errors syscall
------ ----------- ----------- --------- --------- ----------------
 17.19    0.000125           0       126        11 access
 14.44    0.000105           0       126        52 openat
 12.24    0.000089           1        55           mmap
 10.32    0.000075           0        99           read
  8.67    0.000063           4        15           mprotect
  8.25    0.000060           0        94         6 newfstatat
  5.50    0.000040           0        74           close
  5.23    0.000038           0        58        40 readlink
  4.68    0.000034          34         1           set_tid_address
  3.30    0.000024           0        38           getrandom
  3.16    0.000023           1        13           pread64
  1.65    0.000012           0        26           getdents64
  1.51    0.000011           1         9           brk
  1.10    0.000008           4         2           rt_sigaction
  0.83    0.000006           0         9           munmap
  0.55    0.000004           4         1           rt_sigprocmask
  0.55    0.000004           4         1           prlimit64
  0.41    0.000003           3         1           arch_prctl
  0.41    0.000003           3         1           set_robust_list
  0.00    0.000000           0        20           write
  0.00    0.000000           0         1         1 ioctl
  0.00    0.000000           0         1           execve
  0.00    0.000000           0         1           sysinfo
  0.00    0.000000           0        11           fstatfs
  0.00    0.000000           0         8           fadvise64
------ ----------- ----------- --------- --------- ----------------
100.00    0.000727           0       791       110 total
--8<---------------cut here---------------end--------------->8---

Now that is unexpected! There are actually less stats and opens. I'm
stumped! My profile has about 20 font packages (about 450 actual files)
installed. For reference, for both versions, `fc-cache -rf` yields about
3700 stats; and `fc-cache` yeilds about 300...

I suppose I should be more careful about speaking from theory!

>
>> I am not confident this method is fully deterministic; particular filesystem
>> capabilities may still be an implicit imput in the checksums. This should only
>> matter when distributing pre-generated caches.
>>
>> Fontconfig does honor SOURCE_DATE_EPOCH, but without a reliable mtime,
>> fontconfig has no way of knowing when to update such a cache. SOURCE_DATE_EPOCH
>> is now disabled for the tests because they assume working cache invalidation.
>
> So tests fail is we leave SOURCE_DATE_EPOCH, right?

Correct.

> Thanks for addressing this longstanding issue!  (And apologies for the
> delay…  Now’s a good time to get semi-high-level changes like this one
> in ‘core-updates’.)

I still wish we could address it "properly" by generating a cache at
profile generation time... but it looks like fontconfig embeds the full
paths of fonts in the cache (including username, since fonts are under
~/.guix-profile), so I doubt such a cache would work. I plan to try it
eventually anyway (or perhaps someone else will), but in the meantime,
this looks like the 80% solution.

--
Sarah




  reply	other threads:[~2021-07-08  1:28 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-06-19  0:52 [bug#49107] [PATCH core-updates] gnu: fontconfig: Use (locally) deterministic caching Sarah Morgensen via Guix-patches via
2021-07-07 21:16 ` Ludovic Courtès
2021-07-08  1:17   ` Sarah Morgensen via Guix-patches via [this message]
2021-07-12  8:30     ` bug#49107: " Ludovic Courtès

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=86eec9k3it.fsf_-_@mgsn.dev \
    --to=guix-patches@gnu.org \
    --cc=49107@debbugs.gnu.org \
    --cc=iskarian@mgsn.dev \
    --cc=ludo@gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this external index

	https://git.savannah.gnu.org/cgit/guix.git

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.