[Fontconfig] performance issue questions
akira at tagoh.org
Mon Nov 28 01:59:42 UTC 2016
On Sat, Nov 26, 2016 at 3:38 AM, L. A. Walsh <fonts at tlinx.org> wrote:
> Generated per dir, yes, but when you choose a directory to
> update, isn't the time to update it proportional to the number
> of files in that directory? Using an extreme case as an example,
> if you had 10,000 files in that one dir that were all copies
> of 1 of the files and if the program knew that -- couldn't it generate
> the info needed for 1 file and, at worse, duplicate it 9,999 times, to
> avoid the calculation cost for the 9,999 copies (if it "knew" they
> were copies?).
For what to make such copies in the same directory?
IO race? Too much I/O for older machines? Maybe have it
No, the race on updating caches.
As I said, the cache is generated per dirs and the parent cache is also
updated. when caches needs to be updated, that would means fonts were
added/updated/deleted or directories containing a font were
added/updated/deleted. what if some processes is updating the same cache?
what if some processes are updating caches for additions during updating
caches for deletion? and so on. FWIW this isn't a paranoid. is examples
actually happened in the past.
Though fc-cache itself doesn't prevent to do so so far. you could do it
with knowing such risks if you want. I did the workaround as much as I can.
at least I'm not aware of it on the packaging system possibly runs the
scriptlet in parallel but I'm not sure if it is perfect.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Fontconfig