Re: performance issue questions
Akira TAGOH <[email protected]>
| Newsgroups | gmane.comp.fonts.fontconfig |
|---|---|
| Message-ID | <CACT-Cx3ukOhUA5vQQuMMgUUeJoTc9r8ZgZ_CTaBNKbGVU+1v3A@mail.gmail.com> |
On Sat, Nov 26, 2016 at 3:38 AM, L. A. Walsh <[email protected]> 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. -- Akira TAGOH _______________________________________________ Fontconfig mailing list [email protected] https://lists.freedesktop.org/mailman/listinfo/fontconfig