3 ms·

I can't believe a 30% performance improvement has been sitting there.. for 12 Android versions??

wffurr 3y ago
You can read the article and the linked Android developer blog post if you want to get a glimpse of why this is so complicated.
dmitrygr 3y ago
My man…if only you knew 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…
- doomslice 3y ago
  You gotta save that optimization for when performance ends up on a top level OKR!
- refulgentis 3y ago
  Lol. All of my time at G is summed up very elegantly here.
- codethief 3y ago
  What's the reason it never shipped?
- dimator 3y ago
  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.
  - dmitrygr 3y ago
    > I can guarantee 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”.
  - refulgentis 3y ago
    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. EDIT: Here's a thread with similar tales. https://news.ycombinator.com/item?id=36853039 https://news.ycombinator.com/item?id=36853039
    - MBCook 3y ago
      I’ve seen this. 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.
jshier 3y ago
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).
Projectiboga 3y ago
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.

You can read the article and the linked Android developer blog post if you want to get a glimpse of why this is so complicated.

dmitrygr 3y ago

My man…if only you knew 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…

doomslice 3y ago
You gotta save that optimization for when performance ends up on a top level OKR!
refulgentis 3y ago
Lol. All of my time at G is summed up very elegantly here.
codethief 3y ago
What's the reason it never shipped?
dimator 3y ago
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.
- dmitrygr 3y ago
  > I can guarantee 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”.
- refulgentis 3y ago
  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. EDIT: Here's a thread with similar tales. https://news.ycombinator.com/item?id=36853039 https://news.ycombinator.com/item?id=36853039
  - MBCook 3y ago
    I’ve seen this. 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.

jshier 3y ago

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).

Projectiboga 3y ago

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.