Re: RFC: locale-archive optimizing for the primary locale

[Roland McGrath <roland at redhat dot com>]

I am certainly in favor of this sort of optimization.
This one assumes a mode of installing the locale archive
that is not what I had presumed people would do (I had been
thinking most people would just have a single canonical archive
image installed from a distribution package).  But I haven't
thought much about what installers do.

Well more than half the locales are well under a megabyte.
So the plan of eagerly mapping an arbitrary initial region
can be quite small while still winning in many cases.
If one is especially concerned about consuming a couple megs
of address space, having the size of the initial locale in
the header and mapping exactly that will mean <256k for all
the Western locales.  However, with an "optimized for speed" archive
you will only ever need one mmap for the locale once you know
where it is, so the header could as well tell you its location
and then it could be one read + one mmap regardless of location
(you can delay the mmap of the entire header until you have to
look up a different locale).  For most locales, that would in 
fact occupy not much more address space than the whole header
by itself (which you can save if you don't use another locale).

Using an arbitrary size liable to be large enough (the largest
locale now is not much over one megabyte) has the added benefit
that we could skip the read and just do the mmap after the stat.
That only loses in the error case of an archive with a bad header.
I don't know what the cost of the read is, but every bit helps.
I certainly think 2MB of address space is reasonable to give,
and on a tightly-configured system one could install an archive
containing only the primary locale and then the whole file would
be only marginally larger than the data itself and no more AS than
that consumed.