Avoid iterating over all handles in MessagePumpMojo on every iteration to calculate deadlines.

mojo/message_pump/message_pump_mojo.h

Index: mojo/message_pump/message_pump_mojo.h
diff --git a/mojo/message_pump/message_pump_mojo.h b/mojo/message_pump/message_pump_mojo.h
index 06869730eec7a0e1fa83622b3639432e905a744e..50c7812a0d6385c79019dbf07486e000228cb3a2 100644
--- a/mojo/message_pump/message_pump_mojo.h
+++ b/mojo/message_pump/message_pump_mojo.h
@@ -6,6 +6,7 @@
 #define MOJO_MESSAGE_PUMP_MESSAGE_PUMP_MOJO_H_
 
 #include <map>
+#include <set>
 
 #include "base/macros.h"
 #include "base/memory/scoped_ptr.h"
@@ -117,6 +118,10 @@ class MOJO_MESSAGE_PUMP_EXPORT MessagePumpMojo : public base::MessagePump {
   base::Lock run_state_lock_;
 
   HandleToHandler handlers_;
+  // Set of handles that have a deadline set. Avoids iterating over all elements
+  // in |handles_| in the common case (no deadline set).
+  // TODO(amistry): Make this better and avoid special-casing deadlines.
+  std::set<Handle> deadline_handles_;

[sky, 2015/11/17 18:35:11]

If we're really worried about efficiency, why don't we sort this based on
TimeTicks? That way GetDeadlineForWait() need only consult the first element.

[Anand Mistry (off Chromium), 2015/11/17 23:54:39]

Sorting by TimeTicks would make removing by handle require a linear scan over
this. I can't think of an existing structure that would have efficient sorting
by time _and_ efficient insert/removal by handle. I could certainly write one,
but that's more than I wanted to do in this change.

And besides, I scoured codesearch looking for uses of this, and it turns out,
no-one ever sets a deadline. So right now, in 100% of cases, this set will be
empty.

[sky, 2015/11/17 23:58:42]

If no one specifies a deadline, then wouldn't a boolean be simpler? A boolean is
more costly to keep in sync if we do specify deadlines, but as you said, we
don't specify a deadline.

[Anand Mistry (off Chromium), 2015/11/18 00:10:12]

It would, but then if one user does come along and sets a deadline, the
behaviour regresses significantly. My goal is to be better, but not perfect, and
not regress too much if usage changes.

 
   // An ever increasing value assigned to each Handler::id. Used to detect
   // uniqueness while notifying. That is, while notifying expired timers we copy