[Fontconfig] performance issue questions

[Jerry Casiano]

It's not defensive, it's just honest. I'm not a fontconfig dev or fanboy.
And I'm not saying that the library is perfect and needs no improvements
either. I just don't see it as a situation that will change anytime soon,
unless someone is willing and motivated to put in a lot of work for what
certainly seems like an edge case.

As I said originally, I was genuinely curious about the use case, even
apologized for not addressing your questions.

Unfortunately your responses don't seem to touch on that at all.

In any case, have a good day.

On Nov 24, 2016 4:54 AM, "L. A. Walsh" <fonts at tlinx.org> wrote:

> Jerry Casiano wrote:
>
>> On Wed, 2016-11-23 at 21:46 -0800, L. A. Walsh wrote:
>>
>>
>>> Most any X program that has the font name encoded in a config file
>>> for one,
>>>
>>>
>>
>> If you're specifying a font name, then the filepath doesn't matter.
>>
>>
> ---
>    That's true, but its hard to find a utility to rename
> the font-filenames according to their internal name.  I did run
> across one but it only worked for ascii or maybe western character-set
> based names.  Really mangled fonts from other languages.
>
>>
>>
>>>  and second, most windows programs that rely on the user to pick a font
>>>
>>>
>>
>> Selecting a font from a list of thousands of families with some
>> containing 20-30 variations sounds fun.
>>
> ----
>    Actually you usually just have to pick the family name and have
> style sheets select variations based on the usage.
>
>
> Also, the actual filepath wouldn't or at least shouldn't matter there
>> either.
>>
>>
> ---
>    Didn't say it would.
>
>>
>>
>>> Workarounds include technology *growing* to handle larger
>>>>
>>> collections and workloads.
>>>
>>>
>>
>> Sounds like that's the only solution that would satisfy you, so no
>> point in even trying to suggest changes that might ease the pain till
>> that happens.
>>
> ----
>   Uh.... I mentioned the problem over 2 years ago on this list.  I've
> ignore the problem and tried to make due by not touching the fonts
> on linux for the most part.  But after a couple of years, it seems
> like no progress is being made.  I threw out several questions
> that I don't know the answers to -- and you seem to be getting defensive
> from the first response, in asking me "why do you have all those fonts" --
> rather than giving any answers to the questions -- like whether or not
> the 32-bit data is needed on a 64-bit only system, or caching by inode
> and storing names.
>
>> I mean, if you just have to have 15,000 duplicates and 20,000+ font
>> files active at all times then it is what it is.
>>
>>
> ====
>    I didn't create the duplicates.  In fact I *used* to try to delete
> them, but various programs and sources tended to duplicate them.  Linux
> was especially bad in creating symlinks for every font that had spaces
> in it -- those were read by other programs that got confused about which
> was the real name.  Eventually I stopped trying.   If you want to tell
> me font-config can rename all of them to eliminate the dups, that's
> great.  Also trying to rename fonts on windows can also be problematic --
> as some of them are considered "system files" -- remove them (or rename
> them)
> and your system won't boot.
>
>>     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.
>>>
>>>
>>
>> That's interesting...
>>
>> Good for them.
>> That OS would normally slow to a crawl with even a fraction of that
>> figure.
>>
> ---
>   That happened in XP somewhat, and win98 had horrible limitations, but
> in win7 -- no slowdown except at times when you go to display the whole
> list -- can take maybe 30 seconds -- that's tolerable.  12 minutes -- not
> so much.
>
>  That's actually the main reason font management tools came to
>> be, in order to avoid the poor performance and usability caused by
>> having large amounts of fonts active.
>>
>>
> ----
>    Yes, such tools used to be necessary, but I don't see as many
> these days and none that work with the OS.
>
>
>    With 64-bit memory, throwing a Gig or so at a font DB in memory
> would be nothing on many machines.  I throw 4-8G at various server
> programs to allow them to be fast, but you can't do that as easily
> with 32-bit constraints.  Many distros aren't shipping 32-bit binaries
> any more.  So my asking if the 32-bit font-caches even needed to be
> built on machines not using 32-bit progs for graphics (or anything else).
>
> Seems like a reasonable question, but instead of any of my questions being
> answered I get asked why I should be allowed or supported in having so
> many...  If it took 30 seconds to cook the fonts or if it
> happened in background -- wouldn't be as much of an issue, but instead
> of improvement, I am feeling a defensive posture about even asking
> questions about what parts are needed and whether some things are
> necessary, or whether or not things could be made parallel.  Those
> are reasonable questions.
>
> So why am I getting what seems to be defensiveness?
>
>
>
>
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/fontconfig/attachments/20161124/df8890ff/attachment.html>