Quantum Flow Engineering Newsletter #6

[Ehsan Akhgari]

Hi everyone,

I would like to share some updates about some of the ongoing performance
related work.

We have started looking at the native stack traces that are submitted
through telemetry from the Background Hang Reports that take more than 8
seconds.  (We were hoping to have been able to reduce this threshold to
256ms  for a while
now, but the road has been bumpy -- but this should land really soon now!)
Michael Layzell put together a telemetry analysis job that creates a
symbolicated version of this data here:
https://people-mozilla.org/~mlayzell/bhr/.  For example, this
 is the latest
generated report.  The grouping of this data is unfortunate, since the data
is collected based on the profiler pseudo-stack labels, which is captured
after 128ms, and then native stack (if the hang continues for 8 seconds)
gets captured after that, so the pseudo-stack and the native stack may or
may not correspond, and this grouping also doesn't help going through the
list of native stacks and triage them more effectively.  Work is under way
to create a nice dashboard
 out of this data,
but in the mean time this is an area where we could really use all of the
help that we can get.  If you have some time, it would be really nice if
you can take a look at this data and see if you can make sense of some of
these call stacks and find some useful bug reports out of them.  If you do
end up filing bugs, these are super important bugs to work on, so please
make sure you add "[qf]" to the status whiteboard so that we can track the
bug.

Another item worthy of highlight is Mike Conley's Oh No! Reflow! add-on
.  Don't let the simple web page
behind this link deceive you, this add-on is really awesome!  It generates
a beep every time that a long running reflow happens in the browser UI
(which, of course, you get to turn off when you don't need to hunt for
bugs!), and it logs the sync reflows that happened alongside the JS call
stack to the code that triggered them, and it also gives you a single link
that allows you to quickly file a bug with all of the right info in it,
pre-filled!  In fact you can see the list of already filed bugs

through this add-on!

Another issue that I want to bring up is the [qf:p1] bugs.  As you have
noticed, there are a lot of them.  :-)  It is possible that some of these
bugs aren't important to work on, for example because they only affect edge
case conditions that affects a super small subset of users and that wasn't
obvious when the bug was triaged.  In some other cases it may turn out that
fixing the bug requires massive amounts of work that is unreasonable to do
in the amount of time we have, or that the right people for it are doing
more important work and can't be interrupted, and so on.  Whatever the
issue is, whether the bug was mis-triaged, or can't be fixed, please make
sure to raise it on the bug!  In general the earlier these issues are
uncovered the better it is, because everyone can focus their time on more
important work.  I wanted to make sure that this wasn't lost in all of the
rush around our communication for Quantum Flow, my apologies if this hasn't
been clear before.


On to the acknowledgement section, I hope I'm not forgetting to mention
anyone's name here!


   - Bas Schouten made it so that we don't clear the compositor background
   immediately before drawing into it
   .  This made some
   painting and scrolling related benchmarks faster
   , and
fixed a flickering
   issue  in the mean
   time!
   - Mason Chang made the Youtube settings widget less janky
    on Windows with
   D2D when the video is fullscreen.
   - David Baron made the flushes caused by the code that watches your
   mouse to know which side of the window to put the status bar when you hover
   a link less severe 
   .
   - Neil Deakin removed a synchronous layout flush
    that used to
   happen when closing a window which would slow down the window going away.
   - Dão Gottwald removed some obsolete tab animation telemetry
    which could slow
   down tab animations (yes!).  Dão also removed a synchronous layout flush
    which could slow
   down detaching a tab into a new window and he also lazified some
code to avoid
   some more layout flushes
   

Re: windows build anti-virus exclusion list?

[Jeff Gilbert]

Can confirm for Ryzen: FWIW, my stock R7 1800x (RAM @2133Mhz for now
:( ) did a Windows debug clobber in 15:32.40 with the default -j16.
(any directory that showed up as read by MsMpEng in Resource Monitor
excluded for Defender)

I'll give it a run through with Defender disabled, and see if there's
any change.

On Tue, Apr 18, 2017 at 2:17 AM, Marco Bonardo  wrote:
> On Fri, Mar 17, 2017 at 7:20 PM, Ben Kelly  wrote:
>
>> On Fri, Mar 17, 2017 at 1:36 PM, Ted Mielczarek 
>> wrote:
>>
>> With defender
>> disabled the best I can get is 18min.  This is on one of the new lenovo
>> p710 machines with 16 xeon cores.
>>
>
> Just to add one datapoint, I just replaced my desktop with an AMD Ryzen
> 1700x (OC @3.8GHz) and I can clobber in less than 18mins on something that
> may be cheaper than those XEON machines (an OC 1700 can probably do the
> same). I'm currently using -J20, I didn't yet try to bump that up to see
> what's the limit, I'm positive I can get better times out of this machine,
> but I need to find some time for testing.
> I'm using Panda Free, with the SSD containing the sources in its exclusion
> list, didn't do anything to Defender (but I guess it's disabled by having
> another AV in the system).
> You can also disable Defender with a GPO, by setting "Turn off Windows
> Defender" to Enabled.
> ___
> dev-platform mailing list
> dev-platform@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: IPDL now supports async returns with MozPromise

[Bevis Tseng]

On Thu, Apr 20, 2017 at 11:13 PM, Bevis Tseng  wrote:

>
>
> On Thu, Apr 20, 2017 at 10:15 AM, Bevis Tseng  wrote:
>
>> A soft reminder of using AbstractThread::GetCurrent()/MainThread()
>> ​ after some design change for Quantum-DOM.
>>
>> If this message/callback is to be handled on *the main thread of the
>> content process*, please use the replacement called AbstractMainThreadFor
>> 
>> instead.
>>
>> If you're in background thread or not in content process, you are totally
>> fine to use AbstractThread::GetCurrent()/MainThread().
>>
>> ​Note: Precisely speaking, AbstractThread::MainThread() can be used in
> the main thread of chrome process instead.
> It shall never been used in background thread. Hope it was not misleading
> in previous email.
>
I should say that AbstractThread::MainThread() can be used for to dispatch
runnables to the main thread​ in chrome process.

P.S. No more explanation at midnight to make thing worse. :/

Regards,
>> Bevis Tseng
>>
>>
>> On Thu, Apr 20, 2017 at 2:54 AM, Kan-Ru Chen  wrote:
>>
>>> Hello!
>>>
>>> With bug 1313200 landed, async IPC messages can now return data via
>>> MozPromises.
>>>
>>> The IPDL syntax:
>>>
>>> protocol PFoo {
>>> child:
>>> async Bar() returns (bool param);
>>> };
>>>
>>> will generate IPC code that allow the send method like this:
>>>
>>> SendBar()->Then(AbstractThread::GetCurrent(), __func__,
>>> [](bool param) {
>>>   // do something
>>> },
>>> [](PromiseRejectReason aReason) {
>>>   // handle send failure
>>> });
>>>
>>> For a message named Foo it will receive a promise resolver with type
>>> FooPromise. For example the receiving side of previous message
>>> PFoo::Bar the handler looks like this:
>>>
>>> mozilla::ipc::IPCResult
>>> FooChild::RecvBarMessage(RefPtr&& aPromise)
>>> {
>>> bool result;
>>> // do some computation
>>> aPromise->Resolve(result);
>>> }
>>>
>>> If there are multiple return values, they will be wrapped in a
>>> mozilla::Tuple.
>>>
>>> The usual MozPromise rule applies. You can store the promise and
>>> resolve it later. You can direct the ThenFunction to be run on other
>>> threads. If the channel is closed before all promises are resolved,
>>> the pending promises will be rejected with
>>> PromiseRejectReason::ChannelClosed. Promises resolved after channel
>>> close are ignored.
>>>
>>> It is discouraged for the receiving handler to reject the promise. It
>>> should be reserved for the IPC system to signal errors. If you must
>>> reject the promise, only PromiseRejectReason::HandlerRejected is valid
>>> value.
>>>
>>> Please give it a try. In theory this should work for all IPC actors. If
>>> you encountered issues or have ideas to
>>> improve this, please file a bug in Core :: IPC.
>>>
>>> Thanks,
>>> Kanru
>>>
>>> P.S. Note that async constructor or destructor does not support return
>>> promises because the semantic is still not clear.
>>> ___
>>> dev-platform mailing list
>>> dev-platform@lists.mozilla.org
>>> https://lists.mozilla.org/listinfo/dev-platform
>>>
>>
>>
>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: IPDL now supports async returns with MozPromise

[Bevis Tseng]

On Thu, Apr 20, 2017 at 10:15 AM, Bevis Tseng  wrote:

> A soft reminder of using AbstractThread::GetCurrent()/MainThread()
> ​ after some design change for Quantum-DOM.
>
> If this message/callback is to be handled on *the main thread of the
> content process*, please use the replacement called AbstractMainThreadFor
>  instead.
>
> If you're in background thread or not in content process, you are totally
> fine to use AbstractThread::GetCurrent()/MainThread().
>
> ​Note: Precisely speaking, AbstractThread::MainThread() can be used in the
main thread of chrome process instead.
It shall never been used in background thread. Hope it was not misleading
in previous email.

> Regards,
> Bevis Tseng
>
>
> On Thu, Apr 20, 2017 at 2:54 AM, Kan-Ru Chen  wrote:
>
>> Hello!
>>
>> With bug 1313200 landed, async IPC messages can now return data via
>> MozPromises.
>>
>> The IPDL syntax:
>>
>> protocol PFoo {
>> child:
>> async Bar() returns (bool param);
>> };
>>
>> will generate IPC code that allow the send method like this:
>>
>> SendBar()->Then(AbstractThread::GetCurrent(), __func__,
>> [](bool param) {
>>   // do something
>> },
>> [](PromiseRejectReason aReason) {
>>   // handle send failure
>> });
>>
>> For a message named Foo it will receive a promise resolver with type
>> FooPromise. For example the receiving side of previous message
>> PFoo::Bar the handler looks like this:
>>
>> mozilla::ipc::IPCResult
>> FooChild::RecvBarMessage(RefPtr&& aPromise)
>> {
>> bool result;
>> // do some computation
>> aPromise->Resolve(result);
>> }
>>
>> If there are multiple return values, they will be wrapped in a
>> mozilla::Tuple.
>>
>> The usual MozPromise rule applies. You can store the promise and
>> resolve it later. You can direct the ThenFunction to be run on other
>> threads. If the channel is closed before all promises are resolved,
>> the pending promises will be rejected with
>> PromiseRejectReason::ChannelClosed. Promises resolved after channel
>> close are ignored.
>>
>> It is discouraged for the receiving handler to reject the promise. It
>> should be reserved for the IPC system to signal errors. If you must
>> reject the promise, only PromiseRejectReason::HandlerRejected is valid
>> value.
>>
>> Please give it a try. In theory this should work for all IPC actors. If
>> you encountered issues or have ideas to
>> improve this, please file a bug in Core :: IPC.
>>
>> Thanks,
>> Kanru
>>
>> P.S. Note that async constructor or destructor does not support return
>> promises because the semantic is still not clear.
>> ___
>> dev-platform mailing list
>> dev-platform@lists.mozilla.org
>> https://lists.mozilla.org/listinfo/dev-platform
>>
>
>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: IPDL now supports async returns with MozPromise

[smaug]

On 04/20/2017 05:15 AM, Bevis Tseng wrote:

A soft reminder of using AbstractThread::GetCurrent()/MainThread()
​ after some design change for Quantum-DOM.

If this message/callback is to be handled on *the main thread of the
content process*, please use the replacement called AbstractMainThreadFor
 instead.

If you're in background thread or not in content process, you are totally
fine to use AbstractThread::GetCurrent()/MainThread().


Why is using AbstractThread::MainThread() ok in background threads?



Regards,
Bevis Tseng


On Thu, Apr 20, 2017 at 2:54 AM, Kan-Ru Chen  wrote:


Hello!

With bug 1313200 landed, async IPC messages can now return data via
MozPromises.

The IPDL syntax:

protocol PFoo {
child:
async Bar() returns (bool param);
};

will generate IPC code that allow the send method like this:

SendBar()->Then(AbstractThread::GetCurrent(), __func__,
[](bool param) {
  // do something
},
[](PromiseRejectReason aReason) {
  // handle send failure
});

For a message named Foo it will receive a promise resolver with type
FooPromise. For example the receiving side of previous message
PFoo::Bar the handler looks like this:

mozilla::ipc::IPCResult
FooChild::RecvBarMessage(RefPtr&& aPromise)
{
bool result;
// do some computation
aPromise->Resolve(result);
}

If there are multiple return values, they will be wrapped in a
mozilla::Tuple.

The usual MozPromise rule applies. You can store the promise and
resolve it later. You can direct the ThenFunction to be run on other
threads. If the channel is closed before all promises are resolved,
the pending promises will be rejected with
PromiseRejectReason::ChannelClosed. Promises resolved after channel
close are ignored.

It is discouraged for the receiving handler to reject the promise. It
should be reserved for the IPC system to signal errors. If you must
reject the promise, only PromiseRejectReason::HandlerRejected is valid
value.

Please give it a try. In theory this should work for all IPC actors. If
you encountered issues or have ideas to
improve this, please file a bug in Core :: IPC.

Thanks,
Kanru

P.S. Note that async constructor or destructor does not support return
promises because the semantic is still not clear.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform



___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform