There are a couple different reasons crash reports aren't sufficient:
1. Crash reports only report crashes. We need also want to see perf issues like GC and paint jank, etc.
2. Crash reports don't sample the general population, so statistically the information is less useful. If we get a perf issue, it's very important to know whether that issue is suffered by 10% of the users in general pop, or 0.5% of users in general pop. You want to prioritize the stuff that has the greatest impact on the general user population.
Lastly, crash reports are sort of a boolean filter - you only get the people that crash. The things I'd like to know to help in my development are things like "what is the histogram of max GC pause times on docs.google.com". Getting that info requires a good random sampling of the population, not just those who exhibit problems.
1. Then why not add a "perf reporter" and a "paint jank" reporter?
"Hi! It seems that this page is loading unusually slowly, would you mind submitting more details to help Mozilla diagnose the issue?
Click `More Details` to see exactly what information is being reported."
You even already have a good entry point for one of these - the "unresponsive script" dialog.
Personally, I'm far more likely to send you this data (after having looked over it) than even the opt-out case. If I have to opt-out of all data collection to be sure I don't accidentally report www.really-illegal-pornography.com to Mozilla I'll opt out and you'll never see any information from me at all. If I can avoid sending reports for www.reall-illegal-pornography.com but still report lots-of-annoying-javascript.google.com than you'd get more out of me.
2. If the issue is reported 10x more often on docs.google.com than on obscure.yahoo.com only because docs.google.com is far more common (even though the problem happens only on 0.00001% of visits to docs.google.com but on 10% of visits to obscure.yahoo.com) it does indicate that the issue in docs.google.com is more important. Sure it is rarer per visit, but a user is still 10x more likely to encounter it.
> Lastly, crash reports are sort of a boolean filter - you only get the people that crash. The things I'd like to know to help in my development are things like "what is the histogram of max GC pause times on docs.google.com". Getting that info requires a good random sampling of the population, not just those who exhibit problems.
PLEASE do not go down this road. Look where "optimizing" video card drivers has led the video game industry. Game engine developers and game developers are lazier than ever. It is not up to you to make sure docs.google.com runs well on your browser. It is up to you to provide browser that adheres to (and defines if it must) standards. It is up to the web developers at docs dot google dot com to make their application work on Mozilla Firefox.
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.
>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.
> 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.
Uh - these are the most important people. The. Most. Important. The people you just pissed off by taking a header in the middle of whatever it was they are doing. Your performance noodling is irrelevant if you aren't addressing those issues.
I'm sorry, but you make the team sound incredibly out of touch with statements like this. To offset the other platforms advantages in marketing visibility, Mozilla has to be better across the board to survive, so unless you guys aren't crashing at all now, I'd say that this should be job #1.
1. Crash reports only report crashes. We need also want to see perf issues like GC and paint jank, etc.
2. Crash reports don't sample the general population, so statistically the information is less useful. If we get a perf issue, it's very important to know whether that issue is suffered by 10% of the users in general pop, or 0.5% of users in general pop. You want to prioritize the stuff that has the greatest impact on the general user population.
Lastly, crash reports are sort of a boolean filter - you only get the people that crash. The things I'd like to know to help in my development are things like "what is the histogram of max GC pause times on docs.google.com". Getting that info requires a good random sampling of the population, not just those who exhibit problems.