WIP: A couple of more ChannelMojo speedup ideas

WIP: A couple of more ChannelMojo speedup ideas

 1. Add mojo::embedder::SetAsyncMessageCallback()
    The callback is installed to LoalMessagePipeEndpoint, and allows
    the embedder to "steal" arrived mesages before it is enqueued.
    With this, ChromeMojo can bypass subsequent MojoReadMessage() calls.
    13+/-7% speedup for small (14b) message benchmark

 2. Introduce MessageInTransit::ReadContext
    It allows Channel and friends to defer the MessageInTransit instance creation.
    With the async message callback, now ChanelMojo can skip creating MessageInTransit
    instance in many cases and save an extra copying.
    15+/-3% speedup for non-small (hundred-thousand bytes) message benchmark.

R=viettrungluu@chromium.org

[Hajime Morrita, 2015-02-13 23:52:54]

WDYT?

Well, I'm sure you don't like this. But I wonder if the speedup can be worth
harvesting.

I don't think we land this now.
Instead, I'll enable ChannelMojo for Pepper which is more latency sensitive,
see how it affects to their perf, and come back this if it does make things
noticeably slower.

[viettrungluu, 2015-02-14 00:58:30]

On 2015/02/13 23:52:54, morrita wrote:
> WDYT?
> 
> Well, I'm sure you don't like this. But I wonder if the speedup can be worth
> harvesting.

You're probably right :/ but I'll have to look at it more carefully.

A quick question before I run out the door:

For 1., what's the cost breakdown of a MojoReadMessage() call?

(I have various thoughts about things that could be done to improve that --
there's lots of low-hanging fruit that's not unreasonable -- but it'd be good to
know what's going on.)


> 
> I don't think we land this now.
> Instead, I'll enable ChannelMojo for Pepper which is more latency sensitive,
> see how it affects to their perf, and come back this if it does make things
> noticeably slower.

[Hajime Morrita, 2015-02-14 01:23:41]

On 2015/02/14 00:58:30, viettrungluu wrote:
> On 2015/02/13 23:52:54, morrita wrote:
> > WDYT?
> > 
> > Well, I'm sure you don't like this. But I wonder if the speedup can be worth
> > harvesting.
> 
> You're probably right :/ but I'll have to look at it more carefully.
> 
> A quick question before I run out the door:
> 
> For 1., what's the cost breakdown of a MojoReadMessage() call?

Here is a chart from the profiling result:
https://rawgit.com/omo/4f234d1152b5f7793b04/raw/07fd5a17697996cbae0c06bf04bc5...

You can click each bars to zoom in.
base::MessagePumpLibevent::OnLibeventNotification is
where all the things happen and you can find MojoReadMessage() in it. 

It suggests that mutexes costs, but the perf doens't change much (changes only a
few percent)
even we comment out all the locks out. So I'm not sure. Probably small things
visibly accumulate
as the original POSIX version does almost nothing and this is a kind of
microbenchmark.

Here is the ChannelPosix result. It's almost all about system calls.
https://rawgit.com/omo/4f234d1152b5f7793b04/raw/07fd5a17697996cbae0c06bf04bc5...

Here is the one with this CL. MojoReadMessagee() and AsyncWaiter overhead are
gone.
https://rawgit.com/omo/4f234d1152b5f7793b04/raw/4d3da374e752db7db5dbfeaf9544b...


> 
> (I have various thoughts about things that could be done to improve that --
> there's lots of low-hanging fruit that's not unreasonable -- but it'd be good
to
> know what's going on.)
> 
> 
> > 
> > I don't think we land this now.
> > Instead, I'll enable ChannelMojo for Pepper which is more latency sensitive,
> > see how it affects to their perf, and come back this if it does make things
> > noticeably slower.

[chromium-reviews, 2015-02-14 01:48:13]

On Fri, Feb 13, 2015 at 5:23 PM, <morrita@chromium.org> wrote:

> On 2015/02/14 00:58:30, viettrungluu wrote:
>
>> On 2015/02/13 23:52:54, morrita wrote:
>> > WDYT?
>> >
>> > Well, I'm sure you don't like this. But I wonder if the speedup can be
>> worth
>> > harvesting.
>>
>
>  You're probably right :/ but I'll have to look at it more carefully.
>>
>
>  A quick question before I run out the door:
>>
>
>  For 1., what's the cost breakdown of a MojoReadMessage() call?
>>
>
> Here is a chart from the profiling result:
> https://rawgit.com/omo/4f234d1152b5f7793b04/raw/
> 07fd5a17697996cbae0c06bf04bc50b58137b90e/perf_small_mojo.svg
>
> You can click each bars to zoom in.
> base::MessagePumpLibevent::OnLibeventNotification is
> where all the things happen and you can find MojoReadMessage() in it.
>
> It suggests that mutexes costs, but the perf doens't change much (changes
> only a
> few percent)
> even we comment out all the locks out. So I'm not sure. Probably small
> things
> visibly accumulate
> as the original POSIX version does almost nothing and this is a kind of
> microbenchmark.
>

Could you do me a favor and run perf
on CorePerftest.MessagePipe_WriteAndRead (possibly with appropriate
modification -- e.g., one bucket at a time, maybe increasing run time to
get more samples)?

(Once the message has been enqueued, the code path for fetching a message
using MojoReadMessage() should be the same regardless of whether the source
of messages. This would be an even-more-micro-benchmark, of course.)



>
> Here is the ChannelPosix result. It's almost all about system calls.
> https://rawgit.com/omo/4f234d1152b5f7793b04/raw/
> 07fd5a17697996cbae0c06bf04bc50b58137b90e/perf_small_trad.svg
>
> Here is the one with this CL. MojoReadMessagee() and AsyncWaiter overhead
> are
> gone.
> https://rawgit.com/omo/4f234d1152b5f7793b04/raw/
> 4d3da374e752db7db5dbfeaf9544b1036ba98aae/perf_small_hack.svg
>
>
>
>  (I have various thoughts about things that could be done to improve that
>> --
>> there's lots of low-hanging fruit that's not unreasonable -- but it'd be
>> good
>>
> to
>
>> know what's going on.)
>>
>
>
>  >
>> > I don't think we land this now.
>> > Instead, I'll enable ChannelMojo for Pepper which is more latency
>> sensitive,
>> > see how it affects to their perf, and come back this if it does make
>> things
>> > noticeably slower.
>>
>
>
> https://codereview.chromium.org/929433005/
>

To unsubscribe from this group and stop receiving emails from it, send an email
to chromium-reviews+unsubscribe@chromium.org.

[Hajime Morrita, 2015-02-25 19:07:29]

On 2015/02/14 01:48:13, chromium-reviews wrote:
> On Fri, Feb 13, 2015 at 5:23 PM, <mailto:morrita@chromium.org> wrote:
> 
> > On 2015/02/14 00:58:30, viettrungluu wrote:
> >
> >> On 2015/02/13 23:52:54, morrita wrote:
> >> > WDYT?
> >> >
> >> > Well, I'm sure you don't like this. But I wonder if the speedup can be
> >> worth
> >> > harvesting.
> >>
> >
> >  You're probably right :/ but I'll have to look at it more carefully.
> >>
> >
> >  A quick question before I run out the door:
> >>
> >
> >  For 1., what's the cost breakdown of a MojoReadMessage() call?
> >>
> >
> > Here is a chart from the profiling result:
> > https://rawgit.com/omo/4f234d1152b5f7793b04/raw/
> > 07fd5a17697996cbae0c06bf04bc50b58137b90e/perf_small_mojo.svg
> >
> > You can click each bars to zoom in.
> > base::MessagePumpLibevent::OnLibeventNotification is
> > where all the things happen and you can find MojoReadMessage() in it.
> >
> > It suggests that mutexes costs, but the perf doens't change much (changes
> > only a
> > few percent)
> > even we comment out all the locks out. So I'm not sure. Probably small
> > things
> > visibly accumulate
> > as the original POSIX version does almost nothing and this is a kind of
> > microbenchmark.
> >
> 
> Could you do me a favor and run perf
> on CorePerftest.MessagePipe_WriteAndRead (possibly with appropriate
> modification -- e.g., one bucket at a time, maybe increasing run time to
> get more samples)?

Sure, will do.

> 
> (Once the message has been enqueued, the code path for fetching a message
> using MojoReadMessage() should be the same regardless of whether the source
> of messages. This would be an even-more-micro-benchmark, of course.)
> 
> 
> 
> >
> > Here is the ChannelPosix result. It's almost all about system calls.
> > https://rawgit.com/omo/4f234d1152b5f7793b04/raw/
> > 07fd5a17697996cbae0c06bf04bc50b58137b90e/perf_small_trad.svg
> >
> > Here is the one with this CL. MojoReadMessagee() and AsyncWaiter overhead
> > are
> > gone.
> > https://rawgit.com/omo/4f234d1152b5f7793b04/raw/
> > 4d3da374e752db7db5dbfeaf9544b1036ba98aae/perf_small_hack.svg
> >
> >
> >
> >  (I have various thoughts about things that could be done to improve that
> >> --
> >> there's lots of low-hanging fruit that's not unreasonable -- but it'd be
> >> good
> >>
> > to
> >
> >> know what's going on.)
> >>
> >
> >
> >  >
> >> > I don't think we land this now.
> >> > Instead, I'll enable ChannelMojo for Pepper which is more latency
> >> sensitive,
> >> > see how it affects to their perf, and come back this if it does make
> >> things
> >> > noticeably slower.
> >>
> >
> >
> > https://codereview.chromium.org/929433005/
> >
> 
> To unsubscribe from this group and stop receiving emails from it, send an
email
> to mailto:chromium-reviews+unsubscribe@chromium.org.

[Hajime Morrita, 2015-03-24 19:55:53]

OK, I profiled mojo_message_pipe_perftests a couple of message sizes
(12 bytes and 20736 bytes) and made a plot for each.

https://gist.githack.com/omo/6cdd8c4c6ade34dfc6c3/raw/4e001f081494407cd714816...
https://gist.githack.com/omo/6cdd8c4c6ade34dfc6c3/raw/80831a443587c5b2a56c7cd...

Hope this is interesting for you.