On 04/11/2017 07:34 PM, Jason Orendorff wrote:
I have no plans to type in my notes from the JS meeting. If you want them,
ping me on IRC. But one thing I want to think about is how we decide what
to work on, especially performance work. Today, it's like this:

- If you're a volunteer, of course you decide what to pick up—we're just
glad you're here!

- A lot of us profile benchmarks and look for useful work in the profiles.

- Sometimes we do the same thing with random web sites.

- Bigger projects, like Waldo's work on parsing and djvj et al's work on GC
scheduling, are undertaken when we have stuff that has been showing up on
profiles "forever". This kind of work isn't driven by any one particular
measurement, like a benchmark.

Generally, I think we're working on stuff that makes sense (and have been
all along), but it's still not guaranteed to be representative of the web
as users see it. Is that fair? What else should we be doing?

I have looked at multiple performance issues in the past. I globally agree with the processes listed above. The problem I see is that by fixing problem we often forget to look at the big picture, or ask the meta questions.

One of these meta questions is: What parts of our current design includes us writing code to fix performance issues?

The answers to these question are unfortunately larger projects than just fixing a few performance issues observed on websites.

Still, a project like CacheIR is a good answer to this question. Before CacheIR, we had to investigate performance issues of Baseline, and performance issues of Ion. Baseline IC are usually more complete and Ion IC are usually lacking while being more optimized. By unifying the 2 IC systems, CacheIR gives us time to investigate other performance issues in the future.

Our time is the most sparse resource, and the question you asked about how we decide which project is the most important perfectly highlight that we cannot keep up.

--
Nicolas B. Pierron
_______________________________________________
dev-tech-js-engine-internals mailing list
dev-tech-js-engine-internals@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-js-engine-internals

Reply via email to