So I've found two performance issues with this loop.  We can address one of them, but I think the other may require a different approach.

 1. This loop updates every row in the list, but does not modify the height of each row.  Therefore, it is not necessary for the
      visibility_monitor to do a lot of calculations for the resulting mutation events.  Profiling showed that this took a fair bit of time.
      To address this you can pause the monitor before the loop and resume it after the loop.  See the `doRenderTimer()` for an
      example.  Note, however, you will want to check if the monitor exists since it is lazy loaded.
 2. Profiling shows that the app spends about two seconds performing the layout flush after this loop fires.  Of those 2 seconds,
     about 60% of the time is spent recalculating CSS properties and 30% is spent doing reflows.  Its possible that we could
     [optimize the CSS][] as it appears to use some descendant selectors at the moment.  My quick, initial attempts did not help
     much, though.

What do people think about possibly landing this as is so that the export work can proceed?  We could then optimize the performance of the selection mode within the contact list as a separate bug.  As long as the `enterSearchMode()` API remains the same, then those two activities could be done in parallel.

[optimize the CSS]: https://developer.mozilla.org/en-US/docs/Web/Guide/CSS/Writing_efficient_CSS