Fontconfig - Nov 2005 - Re: Fontconfig performance question.

KP> Again, the only reason I see for a binary format is to use shared memory;
KP> if the data need to be reformatted for applications to use them, it 
KP> probably makes more sense to try a more efficient text format file
instead.

That makes sense.  Thanks for the explanation.

                                        Juliusz

Keith,

You haven''t commented on my binary cache idea (email from Friday
10:04).
Was it that stupid? :)

Kris

Around 11 o''clock on May 12, Juliusz Chroboczek wrote:
> Are you sure that a binary format is necessary?  I find the current
> format very convenient for debugging and highly extensible, and I
> would be very grateful if you could make sure that the parser is as
> efficient as possible before going binrary.
I don''t really know.  One significant advantage of a binary format is
that
we could mmap the file read-only and share the memory with all 
applications.
> Please do not make the format overly flexible -- it''s much easier
to
> make a single code path efficient and correct.
The goal is that cache loading be a simple mmap operation; the null 
code-path should prove the most efficient possible.  The question is how 
to structure the data so that it needs no reformatting and yet can be 
efficiently scanned by the font matching algorithm.
> Both byte-swapping and byte-aligned access to data are reasonably fast
> for the amounts of data that we''re dealing with, so unless
profiling
> shows otherwise, the reasonable thing to do is to put everything in
> Motorola-endian byte-aligned form.
Again, the only reason I see for a binary format is to use shared memory; 
if the data need to be reformatted for applications to use them, it 
probably makes more sense to try a more efficient text format file instead.

Perhaps the best thing to do is implement a binary format file and see 
what other problems that causes, and what kind of performance advantage we 
can get.  Then we can decide if the advantages are worth the costs.

-keith

Around 13 o''clock on May 13, Krzysztof Dabrowski wrote:
> You haven''t commented on my binary cache idea (email from Friday
10:04).
> Was it that stupid? :)
I thought I''d answered it indirectly.  Using a binary format file is
mostly
interesting because we could use mmap and share the data among all 
processes, so the format would need to be interpretable without adjusting 
the data.

Secondly, the cache files are per-directory for several reasons, so we 
can''t really save the whole data structure to a single file.
> And about versioning: such things like this cache can be in my opinion
> realy library-version dependant, if the cache is from older version,
> re-creating it takes just a second or two..
I''d prefer to avoid versioning the cache files that frequently; it
makes
distributed environments that share fonts over a network file system more 
difficult to manage, and it clutters the file system with stale cache 
files which may still be needed by some statically linked application.

In my environment, it takes 90 seconds to regenerate the font cache files, 
making it pretty essential that the font installation mechanism be able to 
compute the bulk of the cache contents so that the user isn''t surprised
by
a delay of this length on login or other application startup.

-keith

Keith,

Are you sure that a binary format is necessary?  I find the current
format very convenient for debugging and highly extensible, and I
would be very grateful if you could make sure that the parser is as
efficient as possible before going binrary.

But if you do...

KP> A brute-force approach would be to define structures to pad
KP> appropriately (as the X headers do) and then permit entries for
KP> both byte orders.

Please do not make the format overly flexible -- it''s much easier to
make a single code path efficient and correct.

Both byte-swapping and byte-aligned access to data are reasonably fast
for the amounts of data that we''re dealing with, so unless profiling
shows otherwise, the reasonable thing to do is to put everything in
Motorola-endian byte-aligned form.

                                        Juliusz