Latest Android Runtime (ART) update led to apps starting 30% faster
9to5google.com
9to5google.com
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.
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 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.
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.
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”.