Focus on the performance for Firefox 58 Developer Edition ?

[Julien Wajsberg]

Hey folks !

We talked a lot about the performance of our tools lately, especially
thanks to Alexandre's leadership on this.
So I realized that Firefox 58 Developer Edition should happen slightly
before Firefox 57 Stable.

What does it mean for us ? *It means we still have 1 development period
(⇨ November 13) to focus especially on the stability and the performance
of our tools* so that we can be part of the same message about Quantum.*

*So let's spend the next 6 weeks to land less features, but instead try
our tools with various use cases, especially difficult use cases (eg:
Twitter, CNN, Facebook, JIRA and Confluence, MDN, Slack, Skype Web). I
know landing features is cool, easier to show in newsletters (wink wink)
and presentations, yet from time to time we need to take a step back and
think about what we need at the moment. I believe what we need *now* is
focussing on performance and stability. What do /you/ believe ?

Try them /inside/ Firefox, in not so ideal situations (eg: as a small
sidebar).

If they feel slow, file a bug first *(everybody can do it)*. If the
behavior is suboptimal, file a bug first (ditto). If something's doesn't
work, well, you know the drill.
Only then think whether the use case is important, for example during
triage, and only then you can work on it.

A first step is: investigate on the surface, with a profile if this is a
performance issue, with the debugger if this is a bad behavior, write
down your findings. If possible mark the bug a "mentored" bug once it's
done, maybe a contributor will come to fix it for you. But even without
this you'll help the yourself-of-next-week remembering what this bug was
about.

This is the duty of module owners to assess the quality of their
modules. This is your role to test them and file bugs if necessary. If
you need help because you think there are too much work to do, this is
also your job to ask for help.


So, what do you think ? Yeah, I knew you'd say this :)/Let's do it !/

--
Julien

[Brian Grinstead]

I think it’s a great idea to focus on performance for this release. On that note, if anyone has some spare cycles and can help with console frontend perf, it would be very much appreciated. I’ve been tracking known issues at https://bugzilla.mozilla.org/show_bug.cgi?id=1156747.

* The bulk of these are due to time spent inside of React (even with components preventing unnecessary updates), so any ideas or efforts here would be most welcome.
* There’s also a case with protocol slowness due to a large packet size when requesting Object properties (i.e. a 7.4MB packet is sent cross-process for a large array). If anyone is knowledgable about the CDP format for object prototype/property requests and thinks we should migrate to something that looks more like that or wants to implement a more efficient format for our own packet, then please see Bug 1391077.

Thanks,
Brian

> _______________________________________________
> dev-developer-tools mailing list
> dev-devel...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-developer-tools

[Julien Wajsberg]

Le 02/10/2017 à 20:19, Brian Grinstead a écrit :
> I think it’s a great idea to focus on performance for this release. On that note, if anyone has some spare cycles and can help with console frontend perf, it would be very much appreciated. I’ve been tracking known issues at https://bugzilla.mozilla.org/show_bug.cgi?id=1156747.
>
> * The bulk of these are due to time spent inside of React (even with components preventing unnecessary updates), so any ideas or efforts here would be most welcome.

I have an idea about this: splitting the list in (non-redux connected)
chunks. The idea behind this is that most lines are static once
rendered. That means that most _chunks_ will be static once rendered. So
if we can avoid changing the props for the chunks that don't change, I
believe we can avoid a lot of updates.

The part where we keep  the props that don't change is the part that's
most difficult. But certainly doable.

[Harald Kirschner]

Thanks a lot Julian for the inspiring call to action to focus on quality &
performance!

To capture the performance aspects I created
https://docs.google.com/document/d/1U_0lNALuyTLQiw5mVfa0rTy4jkvJO2NS5Rio_8ryXyk/edit#
to capture all requirements with a product aspect. What is missing is the
last part of triage process to prioritize and bucket (like needs-profile,
needs-investigation, etc) performance bugs; which was also a significant
part of Quantum Flow.

Sole started discussions about the technical debt approach and I tried to
capture it (badly) in the OKRs. We probably need to get more crisp on how
we tackle triaging the backlog efficiently for maximum impact. It would
probably be best to get the component owners together to share their
experiences (P1 vs P2 vs rest; bug vs enhancement, meta bugs, etc).
Thoughts?

On Mon, Oct 2, 2017 at 1:53 PM, Julien Wajsberg <jwaj...@mozilla.com>
wrote:

[Patrick Brosset]

I'm seeing a lot of perf-related bug activity recently, which is really
good to see.

In time, we'll need to move to a more performance-minded culture. A place
where performance is just another quality indicator that is taken into
account seriously very early in the development phase. Just like unit tests
or code reviews for example.
But in the meantime, there are a lot of immediate performance wins we can
have.

So, thank you Julien for the email, thanks Harald for making sense of the
work ahead with this doc, thanks Alex for jumping head first in this, and
thanks to everyone working on perf now.

If you're working on DevTools now, but not on performance improvements,
either staff or volunteer, I encourage you to focus your work toward
performance-related things.
A group effort in this area is how we can really make a difference.

A lot of people tend to parallelize feature work and general maintenance.
Right now your general maintenance time would be very well spent on perf!

If you don't know how to get started, I think the first step is perf.html.
If you haven't done so yet, go there, install the add-on as instructed, and
start profiling DevTools.
There are still low hanging fruits that can be fixed in many parts of
DevTools.
Of course not all parts matter the same way, which is why Harald's doc is
important as it identifies some crucial user flows that are more important
to optimize for.

If you are a volunteer wanting to participate in this bug not sure how, I
think reaching out to people is going to be your best bet.
There are a bunch of people on either IRC or Slack
<https://devtools-html-slack.herokuapp.com/> would can help you: Alex
(ochameau), Honza, Ricky (rickychien), Fred (gasolin), Nicolas (nchevobbe),
Julian (jdescottes), Mike (mikeratcliffe), etc.


On Tue, Oct 3, 2017 at 12:32 AM, Harald Kirschner <har...@mozilla.com>
wrote: