6 years ago an intern in chromeOS using Gem5 found an optimization in how Android’s ART emits code that would help all in-order arm cores(a-5x) to the tune of 10%. A simple fix. He prototyped it. It worked. Fix was a dozen lines. It never shipped…
I love how people say things like "it never shipped" and assume it was all just political or nefarious or ineptitude.
I can guarantee that there was a huge thread about this in the bug, and it was not as simple as "nah don't ship it". There are many technical reasons/tradeoffs involved, and sometimes perfectly reasonable improvements are not possible. That's at every software org.
I'll go ahead and vouch for it, I can't speak to the bug specifically, but everything they've said tracks, and I have a really funny similar story (different orgs).
It's odd, and not what I heard much about FAANG say 5 years ago, but it is what it is.
Among root causes:
- people hate tattletales
- everyone is overworked.
- no second-level manager has enough time or upside to run an investigation every time a first-level manager says "no they forgot about {concurrency|tps report v2.1|memory use}" and another first-level manager, not responsible for the code, says its fine.
- hell, your first-level manager doesn't have upside because it's just conflict. If you got someone knocking around for you, you got a good one.
Even though someone did the work, even with full tests/etc, integrating it will steal time from the testers. Even if it’s only 2h.
That means they might not hit the existing plan, even if it’s a 0.5% chance. So they won’t take the risk. After all, it’s not part of the plan.
So it goes on the backlog for when the roadmap is smaller than capacity (read: never). Because no one is going to push hard enough. That would waste capital needed to get the Blorp team to do the thing needed to complete stuff on your committed roadmap on time so you don’t get screwed and left holding the ball.
And all that is when operating in good faith, assuming the receiving team isn’t pulling NIH or some other nonsense.
This naturally happens when engineering orgs are feature rather than result or quality oriented. As another random example, Apple shipped autolayout in iOS 7 with greater than quadratic performance as the number of constraints increased. It wasn't until iOS 12 that they made it simply linear, a well known optimization of linear algebra systems (autolayout is largely a simultaneous equation solver).
Just startup. 1.5 seconds down to ~1 seconds. The actual improvement is that chunk can get security fixes directly rather than from the device manufactures. This is big for LG phone owners as LG exited the phone business and has stoped updates.
But they don't talk about what they did to improve the speed of ART.
They talk about how they modularized. That's about it. Kind of not really worth reading. Seems more like a, "yay we managed to modularize some things" self congratulation, rather than getting something useful to the community.
because I want companies to inform me about cool things they are releasing? I thought that was the point of these events… but feel free to correct my assumption.
But such updates randomly appearing kind of confirms my idea that Android is generally incredibly inefficient and Google only sometimes cares, to the point of it almost feeling accidental.
Switching to iOS revealed to me how non-shitty a mobile OS can be.
Build a simple Android app, e.g. single activity from default examples, using most recent SDK and all recommended technologies. When compiled it will be 1MB+ in size and take about a second to startup. Take my old Android app from 10 years ago - it starts instantly, dashboard is immediately visible on cold start. Google should simplify Android SDK and move styling framework (Material design) onto device. Apps will be smaller, performance better.
26 comments
[ 4.3 ms ] story [ 64.9 ms ] thread6 years ago an intern in chromeOS using Gem5 found an optimization in how Android’s ART emits code that would help all in-order arm cores(a-5x) to the tune of 10%. A simple fix. He prototyped it. It worked. Fix was a dozen lines. It never shipped…
I can guarantee that there was a huge thread about this in the bug, and it was not as simple as "nah don't ship it". There are many technical reasons/tradeoffs involved, and sometimes perfectly reasonable improvements are not possible. That's at every software org.
Really? Cause only one of us saw this whole thing through from start to end…
It boiled down to “stay in your lane, chromeOS team”.
It's odd, and not what I heard much about FAANG say 5 years ago, but it is what it is.
Among root causes:
- people hate tattletales
- everyone is overworked.
- no second-level manager has enough time or upside to run an investigation every time a first-level manager says "no they forgot about {concurrency|tps report v2.1|memory use}" and another first-level manager, not responsible for the code, says its fine.
- hell, your first-level manager doesn't have upside because it's just conflict. If you got someone knocking around for you, you got a good one.
EDIT: Here's a thread with similar tales. https://news.ycombinator.com/item?id=36853039
Speeding up X isn’t on their roadmap/plan.
Even though someone did the work, even with full tests/etc, integrating it will steal time from the testers. Even if it’s only 2h.
That means they might not hit the existing plan, even if it’s a 0.5% chance. So they won’t take the risk. After all, it’s not part of the plan.
So it goes on the backlog for when the roadmap is smaller than capacity (read: never). Because no one is going to push hard enough. That would waste capital needed to get the Blorp team to do the thing needed to complete stuff on your committed roadmap on time so you don’t get screwed and left holding the ball.
And all that is when operating in good faith, assuming the receiving team isn’t pulling NIH or some other nonsense.
They talk about how they modularized. That's about it. Kind of not really worth reading. Seems more like a, "yay we managed to modularize some things" self congratulation, rather than getting something useful to the community.
Also the article does indeed describe some examples of what was optimized.
You mean marketing party?
(emphasis mine)
But such updates randomly appearing kind of confirms my idea that Android is generally incredibly inefficient and Google only sometimes cares, to the point of it almost feeling accidental.
Switching to iOS revealed to me how non-shitty a mobile OS can be.