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
