Stop rebuilding the task manager list view after every new row added.

chrome/browser/ui/views/task_manager_view.cc

Index: chrome/browser/ui/views/task_manager_view.cc
diff --git a/chrome/browser/ui/views/task_manager_view.cc b/chrome/browser/ui/views/task_manager_view.cc
index 4953308c937007cd97ae6522d7d2a5831553feb1..921a0a0c5d9db791dc38228af09c7696c6fae790 100644
--- a/chrome/browser/ui/views/task_manager_view.cc
+++ b/chrome/browser/ui/views/task_manager_view.cc
@@ -181,10 +181,20 @@ void TaskManagerTableModel::OnItemsAdded(int start, int length) {
   if (observer_)
     observer_->OnItemsAdded(start, length);
   // There's a bug in the Windows ListView where inserting items with groups
-  // enabled puts them in the wrong position, so we just rebuild the list view
-  // in this case.
-  // (see: http://connect.microsoft.com/VisualStudio/feedback/details/115345/)
-  OnModelChanged();
+  // enabled puts them in the wrong position, so we will need to rebuild the
+  // list view in this case.
+  // (see: http://connect.microsoft.com/VisualStudio/feedback/details/115345/).
+  //
+  // Turns out, forcing a list view rebuild causes http://crbug.com/69391
+  // because items are added to the ListView one-at-a-time when initially
+  // displaying the TaskManager, resulting in many ListView rebuilds. So we are
+  // no longer forcing a rebuild for now because the current UI doesn't use
+  // groups - if we are going to add groups in the upcoming TaskManager UI
+  // revamp, we'll need to re-enable this call to OnModelChanged() and also add
+  // code to avoid doing multiple rebuilds on startup (maybe just generate a
+  // single OnModelChanged() call after the initial population).
+
+  // OnModelChanged();
 }
 
 void TaskManagerTableModel::OnItemsRemoved(int start, int length) {