[Fontconfig] Fontconfig performance question.

[Krzysztof Dabrowski]

> Some sort of shared-memory scheme could certainly be helpful in
> also cutting down the memory usage of fontconfig, which, while it
> is much better than it used to be, is still far from tiny.

> IMO, probably better than using SysV shared memory (which would
> require a daemon) is to write a file to disk that can be mem-mapped
> in a shared fashion by the various processes.

After such mapping you would have to "parse" it somehow anyway otherwise you 
will have realy slow access to the whole thing in the memory.

I think that a serialisation to a binary format (something resembling IFF 
format would suffice) on disk would be OK since this can be relatively 
quickly loaded and converted to real structures/lists.

But such serialisation would be realy dependant on the structure format - any 
change in the structure would require a new serialiser.

> An intermediate possibility might be to try to keep things like strings
> and coverage tables in a shared segment, but create real FcPattern
> structures in non-shared memory that point to the shared segment.

> (BTW - I seem to recall some significant speedups that could be made
> in the parsing code when I looked at it.)

This could be beneficial but still it wont solve the problem that  avery 
KDE/Gnome/Xft2 application started in your system will have to re-parse 
everything again and this is a waste of time.

I'm realy not against the daemon thing. It could be realy transparent - if you 
have it up and running - fontconfig could obtain it's data from it. If it's 
not up and running it can fall back to the old behaviour. 30% of app's 
startup time is worth it in my opinion.

best regards,
Kris