This is getting off-topic, but it's interesting. I think I have the exact opposite take on things from you :)

A program written by a developer and used by a user is a relationship between that developer and the user. I just work on the platform that allows that relationship to exist. I feel it's overstepping our boundaries as platform providers to say "we're not going to make this platform faster for you because we think developers are writing bad code using that performance as a crutch".

It feels like I'd be setting myself up as a self-appointed clergy over moral matters in software development. It's not a hat I'm comfortable with.

Why not think about the program you are working on as a program that is built to support the open standards that enable people to communicate and concentrate on performance within these standards? If someone wrote a bad performing non standard compliant code the program should throw an error.

Making bad code run faster is overstepping the boundaries.

But we're not making "bad code" run faster. We're making code run faster. The original counterpoint was that we shouldn't be, because improving the performance just gives leeway for bad programmers to use it as a crutch.

We don't prioritize bad code for optimization. See usage of 'with' in Javascript. We don't actively try to make it worse, but whenever a decision is presented which regresses 'with' performance for gains somewhere else, it'll probably be taken because we don't care about 'with' running fast.

But the example I mentioned: histograms of max GC pause times on a particular website. Or particularly bad janks, or long amounts of time spent in JS which might be the result of poor JS execution..

None of these optimize "bad code". They're just standard platform performance optimizations that help all programs. That will include "bad" programs as well.

THAT is your use case? And this just CAN NOT be done from opt-in? Makes no sense.

If mozilla can't see how utterly insane this is then there is no hope left.

>A program written by a developer and used by a user is a relationship between that developer and the user.

What about the relationship between you/Mozilla and the firefox users? This thread is evidence that at least some of the users are not happy that you are (in their eyes) sacrificing their privacy for future performance gains.

Making optimizations based on telemetry from real world sites doesn't mean you're optimizing for that one site only, like a video driver including hacks for a specific game. For example, shifting an array in Firefox used to be O(n) vs. O(1) in the competition [1]. Improving these sort of code paths benefits the entire web, even if the performance issue is discovered and profiled on docs.google.com.

[1] https://bugzilla.mozilla.org/show_bug.cgi?id=1348772

> Making optimizations based on telemetry from real world sites doesn't mean you're optimizing for that one site only, like a video driver including hacks for a specific game. For example, shifting an array in Firefox used to be O(n) vs. O(1) in the competition [1]. Improving these sort of code paths benefits the entire web, even if the performance issue is discovered and profiled on docs.google.com.

Again, the question should be if something "benefits the entire web", how can we discover it without an opt-out anti-feature? If the answer is we can't, then we don't want it. It is as simple as that.