4 ms·

Code bloat is such a strange phenomenon, the way it almost inevitably grows over time. I’ve recently been noticing this with the Android emulator. I created tw

Code bloat is such a strange phenomenon, the way it almost inevitably grows over time. I’ve recently been noticing this with the Android emulator. I created two emulator instances, API levels 21 and 28 (Android 5 and 9 respectively), identical emulated hardware. The API 21 VM is much faster than the 28 VM. It’s perfectly usable on my Mac where the newer OS is unbearably sluggish. Why is that? With every Android release, there’s a song and dance about the work being done to reduce yank (“Project Butter” etc), so why does it keep getting slower? Google have lots of amazing engineers, the world’s best datacenters and a vast pile of cash, so if they can’t win the fight against bloat, what chance do the rest of us have?

natalyarostova 7y ago
I may be wrong on this, as I've only worked on one software team, not at Google, but at least on my team I notice the intense pressure to deliver new features, as well as new product managers who are evaluated on their ability to work with developers to ship fast, results in performance becoming a second class citizen without a very senior very technical owner who ruthlessly shuts down features and projects to protect these properties. In short, I feel it's more an org problem.
- iainmerrick 7y ago
  I basically agree, but at the same time, companies compete hard over speed and benchmarks, so it’s not like performance isn’t on their radar at all. And yet the bloat problem exists. Maybe they’re focusing too hard on low-level benchmarks (JS execution, 60 FPS rendering, etc) and ignoring overall app performance.
gmueckl 7y ago
The quest for performance is often also a cause for bloat: pushing something into a background thread now requires the UI thread to be aware that the background thread may not have the results yet - a lot of extra ifs around accesses to the data model. A fancy fast algorithm to solve a problem at larger scales faster is often more complex and performs slower with smaller inputs. So while people have added 5k or 10k LOC to the project to make fast for the occasional large input, performance for the smallest possible inputs may have reduced for an order of magnitude or so. Then there are the unavoidable features. Accessibility and localization are in that category. Suddenly you need to do extra work every step of the way. Look up translations, format strings with locale dependent rules, build a model for screen readers to process, alternate UI themes and layouts for vision impaired people... death by 1000 paper cuts, but also too important to ignore.
mankeysee 7y ago
>what chance do the rest of us have? A huge and very easy opportunity. Current software is not just unoptimized, it is antioptimized to the neck. Any idiot could do far better than current "state of the art" if he is raised with prioritizing the correct things and understanding useless layers and crap for what it is.
- iainmerrick 7y ago
  That’s been true for a long time, though. A steady progression since the dawn of computing. If there really is a golden opportunity for somebody to sweep in with vastly faster software, why has nobody done this yet? (Or have they?)

natalyarostova 7y ago

I may be wrong on this, as I've only worked on one software team, not at Google, but at least on my team I notice the intense pressure to deliver new features, as well as new product managers who are evaluated on their ability to work with developers to ship fast, results in performance becoming a second class citizen without a very senior very technical owner who ruthlessly shuts down features and projects to protect these properties. In short, I feel it's more an org problem.

iainmerrick 7y ago
I basically agree, but at the same time, companies compete hard over speed and benchmarks, so it’s not like performance isn’t on their radar at all. And yet the bloat problem exists. Maybe they’re focusing too hard on low-level benchmarks (JS execution, 60 FPS rendering, etc) and ignoring overall app performance.

gmueckl 7y ago

The quest for performance is often also a cause for bloat: pushing something into a background thread now requires the UI thread to be aware that the background thread may not have the results yet - a lot of extra ifs around accesses to the data model. A fancy fast algorithm to solve a problem at larger scales faster is often more complex and performs slower with smaller inputs. So while people have added 5k or 10k LOC to the project to make fast for the occasional large input, performance for the smallest possible inputs may have reduced for an order of magnitude or so. Then there are the unavoidable features. Accessibility and localization are in that category. Suddenly you need to do extra work every step of the way. Look up translations, format strings with locale dependent rules, build a model for screen readers to process, alternate UI themes and layouts for vision impaired people... death by 1000 paper cuts, but also too important to ignore.

mankeysee 7y ago

>what chance do the rest of us have? A huge and very easy opportunity. Current software is not just unoptimized, it is antioptimized to the neck. Any idiot could do far better than current "state of the art" if he is raised with prioritizing the correct things and understanding useless layers and crap for what it is.

iainmerrick 7y ago
That’s been true for a long time, though. A steady progression since the dawn of computing. If there really is a golden opportunity for somebody to sweep in with vastly faster software, why has nobody done this yet? (Or have they?)