On Sat, Dec 12, 2009 at 4:52 AM, Satoru Takabayashi
<sato...@chromium.org> wrote:
> The chrome binary for Linux seems to load resource bundles from a file named
> "chrome.pak", while the resource booundles are embedded in the chrome DLL in
> other platforms (correct me if I'm wrong). This makes me wonder if it's a
> good idea to embed chrome.pak in the chrome binary for Linux. This would
> save open+mmap cost (probably negligible though), and would make the package
> a bit simpler. I guess it can be done with objcopy, without too much work.
> Any thoughts?
I thought about this for a while and I'm not sure there is enough of a
difference either way to make it matter. It seems that having it
within the executable should be nearly identical in terms of startup
cost and memory usage. I guess the code might be slightly less
complicated, but we already pay complexity anyway for locating the
locale data, which remains separate.
If I have any preference, I would prefer it either all one way (all
static data embedded within the executable) or the other (all static
data external to the executable). Right now we're somewhere in the
middle (since ICU data is in the executable) and your proposed change
also leaves us in the middle (since it would leave locale data out of
the executable).
There's maybe one other benefit to consider: the simpler the
executable, the faster the iterative compile/link cycle will be. But
again I wonder if the difference would be enough to measure, since the
resources data is only 1.4mb. (The ICU data is something like 8mb, so
that ought to cost more.)
--
Chromium Developers mailing list: chromium-dev@googlegroups.com
View archives, change email options, or unsubscribe:
http://groups.google.com/group/chromium-dev
