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