Re: Caching strategy improvements

What's with fon files being slow? Please report *that* and let's fix it.

We've made scanning, like, 100x faster already. 2007 stats are irrelevant.
Checksuming files is slower than scanning them now.

On Sun, Feb 25, 2018 at 8:08 AM, Kurt Kartaltepe <[email protected]>
wrote:

> While trying to move a project to the pango stack I noticed the native
> font selection backends were bad/useless on some platforms (like
> windows see [1]). So I opted to try and use fontconfig on all
> platforms as it performs outstandingly and has wonderful defaults for
> all platforms.
>
> However during this transition I noticed that there are some major
> issues with cache build speed and during investigation I see that
> there has recently been effort to improve the situation[2]. From what
> I can tell the fontconfig team has maintained that these cache issues
> were irrelevent for the primary fontconfig platform (linux) [3]. On
> linux of course the cache is global and maintained usually by font
> packages ensuring its up-to-date. However it was precisely this the
> slow cache build times that lead to package managers being required to
> build in additional tooling to support not rebuilding cache for every
> font installed [4].
>
> Anyway I hope that is enough reason to persuade you that there are
> substantial improvements to make to the caching strategy and they are
> beneficial not only for the odd platforms (osx, windows) but also for
> Linux.
>
> My question is if fontconfig would be receptive to building/accepting
> a patch modifying the caching strategy to include checkums per file
> instead of/in addition to per directory. Currently any change to
> directory (such as adding a new font) invalidates all fonts within
> that directory. This means for directories like the system directory
> it results in re scans of hundreds or more fonts. Thankfully this is
> faster on platforms like linux where all fonts on freetype. However
> this improvement in scanning did not carry over to windows with its
> many FNT (150 on the average install) and even on my very robust
> development machine building a cache for a mere 650 files takes half a
> minute. This might be acceptable on install of the application where
> we can take our time building the cache, but what happens when a user
> installs 1 more font? A change to cache individual file checksums
> would provide fontconfig a way to only require the expensive coverage
> check of a single font instead of the entirety of a users. I dare say
> with this exact change the need to use a faster less robust coverage
> check that made scanning freetype fonts faster may be unneeded as the
> number of scans required to rebuild a cache would reduced 100x on the
> average system or more.
>
> I'm certain such a change would be highly appreciated by all
> fontconfig consumers who are hoping to use its powerful feature set in
> a multiplatform context.
>
> --Kurt Kartaltepe
>
> [1] https://bugzilla.gnome.org/show_bug.cgi?id=162681
> [2] https://lists.freedesktop.org/archives/fontconfig/2017-
> August/005986.html
> [3] https://bugs.freedesktop.org/show_bug.cgi?id=64766
> [4] https://lists.freedesktop.org/archives/fontconfig/2007-
> October/002728.html
> _______________________________________________
> Fontconfig mailing list
> [email protected]
> https://lists.freedesktop.org/mailman/listinfo/fontconfig
>



-- 
behdad
http://behdad.org/

_______________________________________________
Fontconfig mailing list
[email protected]
https://lists.freedesktop.org/mailman/listinfo/fontconfig