The Management Fix That Made Firefox Faster
wsj.com
wsj.com
I suspect the truth is programmers were not allowed to focus on speed by management and now those same people are claiming their "fix" is what changed the programmer focus, rather than admitting their own short-sightedness and poor product management.
I love fixing performance issues, finding the refactoring and satisfaction from doing it very rewarding. I assume there are plenty of other programmers that do too.
But it's expensive work which doesn't deliver any functionality and can break things.
I'd be interested to know if you (as a programmer) think I'm wrong. Do other programmers actually hate fixing performance problems?
The first type is where performance drops 40% from one commit/merge/feature/bug fix.
The second type is where performance drops 0.1% a time over 400 commits/merges/features/bug fix.
For the first type, the person who caused the performance drop can just be told to fix it; the solution will almost certainly be a change to code they own. The incentives basically line up. No complex management required!
But for the second type? Nobody would reject a fix for a buffer overflow because bounds checking slowed the code down a little. Fixing such problems might need hundreds of optimisations in different places - or offsetting slowdowns in some areas with speedups in others. Coordinating this sort of thing is what management is supposed to be there for.
Also, it can happen over a bunch of commits and not be one person's fault. An example might be a terribly performing DB query written by Barry but it's only used in an admin interface used once a year, then Sarah checks in a change 2 years later than happens to use the functionality regularly, but it's used every day, by every user.
Additionally, Web apps are very different in a lot of ways as you have one app serving 10, then 100, then 1,000, then 10,000, etc. etc. The performance problems appear from nowhere.
Another example of people deferring performance problems was a system I worked with that processed data, it was non-time critical and poorly written, but was fine when the company had 20 clients as they'd just set it and forget it, that was perfectly acceptable, it wasn't worth fixing. When they got to 100 clients 3 years later, they literally ran out of time in the day.
This is a regular cause of performance problems, terribly written SQL for reports that 5 years ago ran in 10 seconds, annoying but acceptable, but are now taking 2 hours to run.
Here are some examples of other types performance problems:
Problems of scale. The problem only appears when you have X number of orders or on-screen widgets, or when there are more than 200,000 users or whatever. Big O problems. This can be missed because your local db has 1,000 orders and your live one has 1,000,000 (which is a problem in itself, but one I have seen almost everywhere I've worked).
Race conditions. Everything's fine in a test environment, processing 20 orders a minute. When minutes turn into seconds, race conditions occur.
Strange configuration interactions. Problem only appears when you have feature X turned on, with feature Y disabled and feature Z set to option A.
Latency. When the DB/App latency is 0.1ms, the app is good, when it's 3ms, certain pages take >500ms because of hundreds of DB calls.
Bad Indexes/Query Plans/etc/. Problem only appears after your indexes gradually fragment or because the query plan was built when there were 20 things in the DB, and now there are 20 million.
Standard FF footer: I want vertical tab groups back.
When management shifts these priorities, it's not just at the scale of the individual programmer, it's company-wide. Suddenly it's a lot more justifiable to spin up projects for larger-scale performance fixes. Otherwise, you mostly have scattered individual efforts to clean up low-hanging fruit.
Regarding breaking things specifically -- that's one of the clear wins I've found with testing. Something breaks, so you write a test to (a) verify your fix and (b) ensure that you don't break that same thing in the future. Sure, there's extra upfront cost to writing good tests, but that saves you (or your coworkers) debugging effort down the line.
(disclaimer: I work at Google but am not on the Chrome team. These opinions are my own, etc etc.)
... I expected a bit more, to be honest
I hope they one day fix the issues with performance degradation related to profiles. I should not have to reset everything twice a month to keep the same responsiveness.
Are paywalls ok?
It's ok to post stories from sites with paywalls that have workarounds.
In comments, it's ok to ask how to read an article and to help other users do so. But please don't post complaints about paywalls. Those are off topic.