Perf issues with lots of tabs

[Peter Kasting]

Very interesting blog post: http://gregor-wagner.com/?p=79

In short, opening 150 tabs in Chrome/Mac takes a long time and results in excessive CPU and memory use.

Particularly interesting was that when the test script was made to open pages in a way that allowed them to be in new processes, there were 43 renderer processes, but "Some processes only host 2-3 sites and one process hosts about 50% of all sites."  Also, "The main Google Chrome process has 368 threads with 150 open sites and up to 420  during browser shutdown."

This sounds like at the very least,

• We may have a bug in our page -> process allocation code such that too many things are getting dumped into one process
• The browser has too many threads (hundreds? why??)

Probably other perf issues exist as well.

Anyone willing to investigate these?

PK

[Mark Mentovai]

Peter Kasting wrote:
> Very interesting blog post: http://gregor-wagner.com/?p=79
> In short, opening 150 tabs in Chrome/Mac takes a long time and results in
> excessive CPU and memory use.
> Particularly interesting was that when the test script was made to open
> pages in a way that allowed them to be in new processes, there were 43
> renderer processes, but "Some processes only host 2-3 sites and one process
> hosts about 50% of all sites."  Also, "The main Google Chrome process has
> 368 threads with 150 open sites and up to 420  during browser shutdown."
> This sounds like at the very least,
>
> We may have a bug in our page -> process allocation code such that too many
> things are getting dumped into one process
> The browser has too many threads (hundreds? why??)

This could be that our worker pool is unbounded. If a new task gets
dispatched to the worker pool and no worker threads are available to
do it, we just start a new thread without regard for what sort of
shape we’re in thread-wise.

[Scott Hess]

On Thu, Aug 4, 2011 at 12:46 PM, Peter Kasting <pkas...@google.com> wrote:
> The browser has too many threads (hundreds? why??)

Possibly DNS resolution in WorkerPool? I believe that's why Safari
can have thousands of simultaneous threads. Back when we used
OSX-specific code, the system capped the number of outstanding threads
based on available computing resources, and I was never able to fully
convince myself that that was the right thing to do for DNS
resolution, which is mostly waiting around, but I can see that
approach being full of fail once you're spawning so many threads that
their numbers are a problem.

-scott

[Peter Kasting]

On Thu, Aug 4, 2011 at 12:53 PM, Mark Mentovai <ma...@chromium.org> wrote:

If a new task gets

dispatched to the worker pool and no worker threads are available to
do it, we just start a new thread without regard for what sort of
shape we’re in thread-wise.

Sounds like potentially a good bug to file, although I don't know how we make a call on when to avoid starting new threads and what to do in that case.

PK

[Charlie Reis]

On Thu, Aug 4, 2011 at 12:46 PM, Peter Kasting <pkas...@google.com> wrote:

Very interesting blog post: http://gregor-wagner.com/?p=79

In short, opening 150 tabs in Chrome/Mac takes a long time and results in excessive CPU and memory use.

Particularly interesting was that when the test script was made to open pages in a way that allowed them to be in new processes, there were 43 renderer processes, but "Some processes only host 2-3 sites and one process hosts about 50% of all sites."  Also, "The main Google Chrome process has 368 threads with 150 open sites and up to 420  during browser shutdown."

This sounds like at the very least,

• We may have a bug in our page -> process allocation code such that too many things are getting dumped into one process

I'll investigate this one.

Charlie

[Eric Roman]

Getting a dump showing the thread callstacks would be the best way to proceed.

It certainly could be worker pool threads, however note that we limit
the number of outstanding DNS requests to 8, so there shouldn't be an
unbounded explosion of threads from this. (It is possible to exceed 8
parallel DNS threads by cancelling requests, but doesn't sound like
the test-setup is tickling that).

> --
> Chromium Developers mailing list: chromi...@chromium.org
> View archives, change email options, or unsubscribe:
> http://groups.google.com/a/chromium.org/group/chromium-dev
>

[Charlie Reis]

On Thu, Aug 4, 2011 at 1:55 PM, Charlie Reis <cr...@chromium.org> wrote:

On Thu, Aug 4, 2011 at 12:46 PM, Peter Kasting <pkas...@google.com> wrote:

Very interesting blog post: http://gregor-wagner.com/?p=79

In short, opening 150 tabs in Chrome/Mac takes a long time and results in excessive CPU and memory use.

Particularly interesting was that when the test script was made to open pages in a way that allowed them to be in new processes, there were 43 renderer processes, but "Some processes only host 2-3 sites and one process hosts about 50% of all sites."  Also, "The main Google Chrome process has 368 threads with 150 open sites and up to 420  during browser shutdown."

This sounds like at the very least,

• We may have a bug in our page -> process allocation code such that too many things are getting dumped into one process

I'll investigate this one.

Charlie

His comment about Chrome's process assignment looks like a bug with our reporting in the about:memory page, rather than with the process model.  I just ran his script with Chrome's Task Manager open, and we had a pretty even distribution of tabs to processes.

When I visited about:memory, though, it had each page listed twice-- once in its actual process and a second time in the original MemBench process.  That's probably why it looked like half the tabs were in one process.

Looks like this happens for any renderer-initiated cross-process navigations, like using the window.open trick mentioned in the blog post (or using a rel=noreferrer target=_blank link).

I've filed http://crbug.com/91757 to get it fixed.  Anyone know who might be familiar with the about:memory page?

(Another note from running the test myself-- Chrome does indeed get *very* slow with 150 tabs, and it would be great to find ways to improve it.)

Thanks,

[Wez]

On 4 August 2011 16:44, Charlie Reis <cr...@chromium.org> wrote:

(Another note from running the test myself-- Chrome does indeed get *very* slow with 150 tabs, and it would be great to find ways to improve it.)

Is that with Task Manager visible, by any chance?

Wez

 

[John Tamplin]

I personally use tons of tabs, and found Chrome to be very slow in handling startup, since it tries to open them all at once rather than spreading them out.

When I previously mentioned issues with lots of tabs, I was pointed to a doc showing that most users only had a few tabs and it was implied my usage wasn't one that we particularly cared about supporting. If that is different now, then I can report various problems.

--
John A. Tamplin
Software Engineer (GWT), Google

[Charlie Reis]

Yes, the Task Manager was visible when I ran it the first time.  I'm running it again without the Task Manager showing, and it's still very slow, even on a fairly powerful desktop.

Do you suspect the Task Manager is one of the contributing factors?

Charlie

[Wez]

On 4 August 2011 18:05, Charlie Reis <cr...@chromium.org> wrote:

Yes, the Task Manager was visible when I ran it the first time.  I'm running it again without the Task Manager showing, and it's still very slow, even on a fairly powerful desktop.

Do you suspect the Task Manager is one of the contributing factors?

I've noticed that on less powerful Linux platforms (e.g. laptops) , displaying Task Manager seems to raise the Browser process' CPU usage by ~1% for each open tab.  That was only when Task Manager was active, and it seemed to break down evenly between time spent refreshing process stats and time spent updating the display.

It sounds like what's being described here is something more fundamental.

Wez

[Elliot Glaysher (Chromium)]

On Thu, Aug 4, 2011 at 6:13 PM, Wez <w...@chromium.org> wrote:
> I've noticed that on less powerful Linux platforms (e.g. laptops) ,
> displaying Task Manager seems to raise the Browser process' CPU usage by ~1%
> for each open tab.  That was only when Task Manager was active, and it
> seemed to break down evenly between time spent refreshing process stats and
> time spent updating the display.

That's because we get our information out of parsing /proc/<pid>/. The
code that does this is in base/process_util_linux.cc and the bulk of
the time is running GetWorkingSetKBytes which has to read smaps files.
I don't know if there are any kernel interface here or how this could
be improved.

-- Elliot

[Peter Kasting]

On Thu, Aug 4, 2011 at 5:49 PM, John Tamplin <j...@google.com> wrote:

I personally use tons of tabs, and found Chrome to be very slow in handling startup, since it tries to open them all at once rather than spreading them out.

Slow startup is a real but IMO separate issue.  This actually came up just the other day and I filed a bug suggesting we prioritize network requests for foreground tabs (we already prioritize renderers for foreground tabs).

When I previously mentioned issues with lots of tabs, I was pointed to a doc showing that most users only had a few tabs and it was implied my usage wasn't one that we particularly cared about supporting. If that is different now, then I can report various problems.

I'm not sure I'd describe our attitude as "don't care" so much as "this is rare enough that we should allocate resources accordingly".  I'd rather fix a less serious bug that hits tons of users than one that's more crippling but only at >100 tabs.  However, that doesn't make the latter unimportant, and I thought we at least used to be usable at large numbers of tabs, so I'm concerned that (a) this may be a regression and (b) there may be low-hanging fruit here that can at least get us up to par with Firefox.

PK

[Mark Mentovai]

Elliot Glaysher wrote:
> That's because we get our information out of parsing /proc/<pid>/. The
> code that does this is in base/process_util_linux.cc and the bulk of
> the time is running GetWorkingSetKBytes which has to read smaps files.
> I don't know if there are any kernel interface here or how this could
> be improved.

Sadly, I think /proc is supposed to be the kernel interface for this on Linux.

[John Tamplin]

On Thu, Aug 4, 2011 at 9:19 PM, Peter Kasting <pkas...@google.com> wrote:

I'm not sure I'd describe our attitude as "don't care" so much as "this is rare enough that we should allocate resources accordingly".  I'd rather fix a less serious bug that hits tons of users than one that's more crippling but only at >100 tabs.  However, that doesn't make the latter unimportant, and I thought we at least used to be usable at large numbers of tabs, so I'm concerned that (a) this may be a regression and (b) there may be low-hanging fruit here that can at least get us up to par with Firefox.

Well, Firefox also has some issues starting up with lots of tabs, plus it is more likely for everything to be sluggish due to a misbehaving tab, so I don't know that it is much worse than FF there already.  I haven't noticed Chrome being particularly good about restoring a huge number of tabs since v4 or so when I started using it regularly, so I don't think I would call it a regression either.

As far as simple things that would help make it more usable with lots of tabs, there is currently no way to directly select tabs after the title bar tabs overflow the space available (which also makes it exceedingly hard to select empty titlebar area) makes it hard to use Chrome as well as FF with lots of tabs.  I would be happy with horizontal scrollbars and/or a drop-down menu like recent FF.

[Peter Kasting]

On Thu, Aug 4, 2011 at 6:59 PM, John Tamplin <j...@google.com> wrote:

As far as simple things that would help make it more usable with lots of tabs,

Don't worry, we're already very aware of usability issues with this many tabs (there are legion).

PK