[chromium-dev] Re: Question about chromium architecture
On Wed, Jun 3, 2009 at 11:09 PM, Mike Belshe mbel...@google.com wrote: On Wed, Jun 3, 2009 at 10:40 PM, Meryl Silverburgh silverburgh.me...@gmail.com wrote: On Tue, Jun 2, 2009 at 5:00 PM, Brett Wilson bre...@chromium.org wrote: On Tue, Jun 2, 2009 at 4:57 PM, Meryl Silverburgh silverburgh.me...@gmail.com wrote: I am reading this document http://dev.chromium.org/developers/how-tos/getting-around-the-chrome-source-code; about chromium source code: It said: renderer: Code for the subprocess in each tab. This embeds WebKit and talks to browser for I/O. Does that mean chromium do not use the HTTP stack/library that Webkit is using? WebKit uses different HTTP stacks depending on the port. We use a different one than any other ports. And does that mean all the I/O of each tab (webkit renderer) will be sent to 'browser' for I/O, and there is 1 I/O thread in the browser to handle the I/O requests from ALL tab? Correct. That you. But if all I/O of the tab will be sent to and queued up in 1 I/O thread in 'browser', will that become the bottleneck (as supposed to each tab has its own i/o thread and each can load thing independently)? The rule is that the work done on the io thread needs to be very very quick. So far, we've been reasonably successful at that. We use automated tests to search for regressions. But these are just theories. Run it in the profiler, and see for yourself if it works well :-) Thank you for your clarification. If i understanding correctly, I/O thread needs to http request network resources (e.g. image files, js files, css files). And how fast that http request is done is dependent on how far the other end sending the file back, right? So it is not up to chromium find each i/o request very very quick. Am i right? And does browser I/O thread gives priority to I/O from the current active tab (the only tab which is in the foreground)? If it ever profiles as a bottleneck, then we should definitely add priorities. Right now, we don't do much. Background tabs do take background priorities, which indirectly helps. Mike Brett --~--~-~--~~~---~--~~ 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: Question about chromium architecture
On Thu, Jun 4, 2009 at 12:30 AM, Meryl Silverburgh silverburgh.me...@gmail.com wrote: On Wed, Jun 3, 2009 at 11:09 PM, Mike Belshe mbel...@google.com wrote: On Wed, Jun 3, 2009 at 10:40 PM, Meryl Silverburgh silverburgh.me...@gmail.com wrote: On Tue, Jun 2, 2009 at 5:00 PM, Brett Wilson bre...@chromium.org wrote: On Tue, Jun 2, 2009 at 4:57 PM, Meryl Silverburgh silverburgh.me...@gmail.com wrote: I am reading this document http://dev.chromium.org/developers/how-tos/getting-around-the-chrome-source-code about chromium source code: It said: renderer: Code for the subprocess in each tab. This embeds WebKit and talks to browser for I/O. Does that mean chromium do not use the HTTP stack/library that Webkit is using? WebKit uses different HTTP stacks depending on the port. We use a different one than any other ports. And does that mean all the I/O of each tab (webkit renderer) will be sent to 'browser' for I/O, and there is 1 I/O thread in the browser to handle the I/O requests from ALL tab? Correct. That you. But if all I/O of the tab will be sent to and queued up in 1 I/O thread in 'browser', will that become the bottleneck (as supposed to each tab has its own i/o thread and each can load thing independently)? The rule is that the work done on the io thread needs to be very very quick. So far, we've been reasonably successful at that. We use automated tests to search for regressions. But these are just theories. Run it in the profiler, and see for yourself if it works well :-) Thank you for your clarification. If i understanding correctly, I/O thread needs to http request network resources (e.g. image files, js files, css files). And how fast that http request is done is dependent on how far the other end sending the file back, right? So it is not up to chromium find each i/o request very very quick. Am i right? Sure, but the thread is completely idle while we wait for the network and can therefore do other things. The amount of CPU to fetch network resources is tiny compared to the time to render them. The IO thread is effectively a dispatcher here; he gets the network requests started, and does mild processing of data when it arrives. But he hands the real work to the renderer and the webkit thread. Again, if you think there is a problem, open it up in a profiler. I've run the profiler many times, and I don't think this is a bottleneck. Mike And does browser I/O thread gives priority to I/O from the current active tab (the only tab which is in the foreground)? If it ever profiles as a bottleneck, then we should definitely add priorities. Right now, we don't do much. Background tabs do take background priorities, which indirectly helps. Mike Brett --~--~-~--~~~---~--~~ 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: Question about chromium architecture
On Tue, Jun 2, 2009 at 5:00 PM, Brett Wilson bre...@chromium.org wrote: On Tue, Jun 2, 2009 at 4:57 PM, Meryl Silverburgh silverburgh.me...@gmail.com wrote: I am reading this document http://dev.chromium.org/developers/how-tos/getting-around-the-chrome-source-code; about chromium source code: It said: renderer: Code for the subprocess in each tab. This embeds WebKit and talks to browser for I/O. Does that mean chromium do not use the HTTP stack/library that Webkit is using? WebKit uses different HTTP stacks depending on the port. We use a different one than any other ports. And does that mean all the I/O of each tab (webkit renderer) will be sent to 'browser' for I/O, and there is 1 I/O thread in the browser to handle the I/O requests from ALL tab? Correct. That you. But if all I/O of the tab will be sent to and queued up in 1 I/O thread in 'browser', will that become the bottleneck (as supposed to each tab has its own i/o thread and each can load thing independently)? And does browser I/O thread gives priority to I/O from the current active tab (the only tab which is in the foreground)? Brett --~--~-~--~~~---~--~~ 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: Question about chromium architecture
On Tue, Jun 2, 2009 at 4:57 PM, Meryl Silverburgh silverburgh.me...@gmail.com wrote: I am reading this document http://dev.chromium.org/developers/how-tos/getting-around-the-chrome-source-code; about chromium source code: It said: renderer: Code for the subprocess in each tab. This embeds WebKit and talks to browser for I/O. Does that mean chromium do not use the HTTP stack/library that Webkit is using? WebKit uses different HTTP stacks depending on the port. We use a different one than any other ports. And does that mean all the I/O of each tab (webkit renderer) will be sent to 'browser' for I/O, and there is 1 I/O thread in the browser to handle the I/O requests from ALL tab? Correct. Brett --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
