Evan,
Thank you for the detailed feedback. It looks there won't be a much
difference so I'll just forget about the idea.
Thanks,
Satoru
On Sun, Dec 13, 2009 at 12:36 PM, Evan Martin <e...@chromium.org> wrote:
> 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
