On Mon, Dec 14, 2009 at 12:02 PM, Tony Chang wrote:
> I have considered the possibility of moving the resources on Windows out of
> chrome.dll. I made a change a few weeks back that moved theme resources
> into chrome.dll and there was no noticeable change on the bots. I imagine
> moving them back out (along with chrome resources) would not slow down
> startup on the bots either.
>
> The benefit to doing this would be that small changes to the resources file
> wouldn't cause a relink, which is exceptionally painful on Windows.
>
>
> On Sat, Dec 12, 2009 at 9:33 PM, Satoru Takabayashi
> <sato...@chromium.org>wrote:
>
>> 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
>>
>
>
--
Chromium Developers mailing list: chromium-dev@googlegroups.com
View archives, change email options, or unsubscribe:
http://groups.google.com/group/chromium-dev
