-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/30808/#review72803
-----------------------------------------------------------



3rdparty/libprocess/src/clock.cpp
<https://reviews.apache.org/r/30808/#comment118878>

    Do this in clock::pause() once instead of multiple places. improves 
readability. Here and below.


- Joris Van Remoortere


On Feb. 12, 2015, 11:14 p.m., Joris Van Remoortere wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/30808/
> -----------------------------------------------------------
> 
> (Updated Feb. 12, 2015, 11:14 p.m.)
> 
> 
> Review request for mesos, Benjamin Hindman, Ben Mahler, Jie Yu, Niklas 
> Nielsen, and Vinod Kone.
> 
> 
> Bugs: MESOS-2325
>     https://issues.apache.org/jira/browse/MESOS-2325
> 
> 
> Repository: mesos
> 
> 
> Description
> -------
> 
> 1) Maintain an outstanding timers stack to prevent scheduling multiple delay 
> functions for the same timeout.
> 
> Ended up moving tick() into the clock namespace to make it more clear that 
> scheduleNext() and tick() share this global stack of outstanding timeouts.
> 
> The original behavior used a single timer and adjusted the timeout. We didn't 
> go back to this as benh wanted a generalized way to delay an arbitrary 
> function. Therefore we handle the maintenance of this optimization in 
> scheduleNext() and tick() rather than pushing it down into the delay_function 
> and management of ev_timers.
> 
> 
> Diffs
> -----
> 
>   3rdparty/libprocess/src/clock.cpp b92d5de2631986506361e28c05cb6169e6632a70 
> 
> Diff: https://reviews.apache.org/r/30808/diff/
> 
> 
> Testing
> -------
> 
> make check
> A worst-case scenario test for the example listed in MESOS-2325. Constructed 
> many timers in decrementing time (i.e. 500, 499,498, etc.). CPU utilization 
> during this test went down greatly and is on par with code prior to the clock 
> refactoring changes.
> Ran this test with 25K timers, with 10 firing every millisecond. ~3% cpu 
> usage on a macbook.
> 
> 
> Thanks,
> 
> Joris Van Remoortere
> 
>

Reply via email to