[Fontconfig] performance issue questions

[L. A. Walsh]

Jerry Casiano wrote:
>
> Actually, given the above it brings up more questions, at least for me.
>
> Why are you keeping fifteen thousand duplicates?
> Whether they are links or actual duplicates is really besides the point.
>
> And what programs do you require that concern themselves with font 
> filenames and would fail if the filename were to change? Seems like 
> broken behavior.
>
Most any X program that has the font name encoded in a config file for 
one, and second, most windows programs that rely on the user to pick a 
font -- though they won't care about case changes.  Probably *most* of 
them are either case changes, OR some of them that are "shortened". 

> Do all twenty thousand plus actual font files need to be available to 
> everything at all times?
>
====
    Unlikely, but I don't know which will break what if I start randomly 
deleting.  I *try* to go through them in batches once in a while, but 
it's hard to make progress against a collection that's been building for 
15+ years.
But I'm sure many of the fonts are ones I could throw out --- IF I knew
which ones they were. 

    Soooo... Windows 7 came out ... 5-7 years ago and it could handle large
numbers of fonts (it is not bad at doing some organization).

    Windows *ignores* the duplicates (it recognizes fonts with the same
internal data as being duplicates) and it puts them into families.

    Those 21K font files get reduced into about 4400 different font
faces with many or most having multiple variations.  Have seen some that
seem to have 20-30 variations -- maybe 10"ish" names with various types
of obliques/italics/multiple levels of thickness and stylistic variations.

    Given that, if I'm careless about deleting fonts, I could start
deleting variations from families, which wouldn't be good.

    I'm giving the "raw" numbers from linux, but the font software
builtin to win7 7 years ago organized them into a fraction of the
file numbers by families.  Most are familiar with at least having
4 files/fontface for normal,bold,italic and bold-italic, but for
some fonts they get extended into various weight and variations for
titles or fancy-capitals. 

    So even though I have software that can supposedly help me
group things, it doesn't do as good a job as the abandoned(?)
fontmatrix which seemed to do the best job of coming up with
font similarities.


> Sorry, I know I didn't answer your questions. But I am genuinely 
> curious about your use case and whether there are workarounds that 
> might be acceptable to you.
>
----
    Workarounds include technology *growing* to handle larger 
collections and workloads.  I ask about parallel processing -- one point 
in time converting
music from wav->mp3 took > realtime, when flac came along, it was 
slower, but
cpu's made up the pace to give usually give realtime conversion.  When
parallelism came along, I first wrote a shell script to monitor # of
running conversion progs... very primitive, but eventually wrote a perl
script using semaphores that can have the parallelism specified, yield
about a 30-45 second encode time for nearly any album (single-song albums
are the most likely to hit the limits) on a 12-core (2-CPU) home
server.

    If windows could handle 25K fonts 7 years ago (as some smaller
number of grouped font families), I don't see why solutions today can't
be faster and more capable.

    Why is building a cache so slow (I think windows does it in background
each boot, but given it being closed source, I really have no idea).  What
does building a fontcache entail?  If no file data changes, should it
really need to rebuild the whole cache?  Could it use the time/date stamp
as an indicator for rebuilding a single font -- or if a single font
changes, wouldn't it be possible to only update that font?

    Including the list on the response as was intended...