[chromium-dev] Re: Mac renderer launch (Was: Why is Linux Chrome so fast?)
On Oct 28, 2009, at 11:08 AM, Mark Mentovai wrote: My proposal is to fork a new process, exec the renderer, and then let it bring itself up. That's exactly how we start renderers now. The only difference is that I'm suggesting we should always keep a spare one warmed up and ready to go, How much would that increase memory use? (says the guy on the Memory task force...) I.e. what's the RPRVT of a warmed-up renderer process? and we should start the initial one sooner instead of waiting for something in the browser to say um, I'm gonna need a renderer. We can pretty much guarantee that we'll always need a renderer, let's give it a head start. If bringing up the first renderer is CPU-bound, that would be a great idea. If it's disk-bound, then it could have a negative effect on launch time. Do we have profiles/samples of renderer launch, both warm and cold? —Jens --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: Mac renderer launch (Was: Why is Linux Chrome so fast?)
Jens Alfke wrote: How much would that increase memory use? (says the guy on the Memory task force...) I.e. what's the RPRVT of a warmed-up renderer process? Does it matter? At least for the startup case, that's a renderer we know we'll need anyway. You could use this argument to shoot down keeping a spare warmed-up renderer ready to go at other times, but I don't think it's relevant to the startup case. If bringing up the first renderer is CPU-bound, that would be a great idea. If it's disk-bound, then it could have a negative effect on launch time. Do we have profiles/samples of renderer launch, both warm and cold? I suspect that most (but not all) of the stuff that the renderer needs to read to warm itself up will already be in the buffer cache. The renderer shouldn't be doing much writing. But we could profile it. Mark --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: Mac renderer launch (Was: Why is Linux Chrome so fast?)
On Oct 28, 2009, at 11:29 AM, Mark Mentovai wrote: You could use this argument to shoot down keeping a spare warmed-up renderer ready to go at other times, but I don't think it's relevant to the startup case. We weren't just talking about startup — f'rinstance, Darin mentioned new-tab jank. I suspect that most (but not all) of the stuff that the renderer needs to read to warm itself up will already be in the buffer cache. Not on a cold launch, since the renderer uses a lot of code (like WebCore) that the browser doesn't, and will be paging that stuff in. We'll need to benchmark both scenarios. —Jens --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: Mac renderer launch (Was: Why is Linux Chrome so fast?)
On Wed, Oct 28, 2009 at 3:12 PM, Jens Alfke s...@google.com wrote: Not on a cold launch, since the renderer uses a lot of code (like WebCore) that the browser doesn't, and will be paging that stuff in. We'll need to benchmark both scenarios. Indeed. Proof of concept code that we can compare hard numbers about is always better than speculation :-). --Amanda --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
