4 ms·

I was stunned how many engineers I met at Google who didn't know memory allocation takes a ton of time, didn't fundamentally believe it when you told them, and

I was stunned how many engineers I met at Google who didn't know memory allocation takes a ton of time, didn't fundamentally believe it when you told them, and just sort of politely demurred on taking patches for it - first get me data, then walk me through the data, then show me how to get the data myself, then silence, because profiling ain't trivial. There's a 3x speedup sitting in a library because it's in a sea of carefully optimized functions manipulating floats, and someone made a change to extract a function that returned an array. It was such a good Chesterton fence: change seemed straightforward and obvious, better readability. But, it had cascading effects that essentially led to 9 on-demand array allocations in the midst of about 80 LOC of pure math. In my experience, there's hangover from two concepts: - Android does garbage collection and Android is slower than iOS - You can always trade CPU time for memory and vice versa (ex. we can cache function results, which uses more memory, but less CPU)

pjmlp 3y ago
> Android does garbage collection and Android is slower than iOS Thing is, not only has Android runtime witness several JIT and GC refactorings since Darwin was created, originally worse than Sony and Nokia's J2ME implementations regardless of Google's marketing otherwise, there are so many factors contributing to Android's perceived slowness from bad coded UIs, sloppy programing, cheapstakes OEMs with low performance chips, and so on. On the other hand on iOS side, due to lack of GC and OS paging, when memory goes bad, applications just die.
toast0 3y ago
> Android does garbage collection and Android is slower than iOS There's a lot of things going on that make this the case. Android was built with unrestrained multitasking; there's a lot of restraint now, but there's probably still a ton of stuff going on from unrelated processes while your foreground app is chugging along. iOS locks down background execution, and I suspect system apps have limited background execution as well. Less task switching and less cache pollution help a lot. iOS only runs on premium phones. Even Apple's lower priced phones are premium phones. Android isn't necessarily quick on premium phones, but it can be much worse on phones designed to a $50 price point. IMHO, A large issue is that the official UI toolkits are terribly slow. I'm more of a backend person, but I put together a terrible weather app, and first paint is very slow, even though it starts with placeholder data (or serialized data from a previous run); using an HTML view was much faster because it only makes one toolkit objeft and more capable because css layout lets you wrap text around an image nicely. Maybe there's some trick I'm not aware of to make 'native ui' not terrible on Android... but that experience helped me understand why everything is so slow to start.
- mst 3y ago
  If it's slower than a webview, I strongly suspect you're holding it wrong. However "if you do it the naive/obvious way, it performs this badly" is not a good property of a system and still probably explains why so many things are dog slow to get going. (I doubt I'd do any better than you did myself, mind, I'm pretty sure I have even less idea what I'm doing on android than you do) I'd be willing to bet the price of a pint that if either of us flailed around on iOS instead we'd probably end up with much better startup time even hardware-for-hardware because the easiest path for us to flail down is probably much saner than the equivalent on android. (insert rant about APIs needing to make sure the natural path that a newbie takes is also a path that produces -good- results even if they'll still need to git gud to achieve -excellent- results)
  - toast0 3y ago
    > If it's slower than a webview, I strongly suspect you're holding it wrong. I sincerely hope you're right. But I was following the path as best I could, so I'm just not sure how it could have gone so wrong. I do 100% agree with your assessment of my flailing though. ;) It wasn't the only source of frustration (the weather API I was using looked good, but is actually crap, and their support blew me off when I pointed out data inconsistencies, so that's ugh). So it was easy to discard. Back to weather prediction by induction.
    - refulgentis 3y ago
      I was an iOS dev for 7 years before G, then iOS app for Android watches for a year or two, then Android proper for...4 years? 100% cosign on the UI toolkit being.......ugh. There's a general saying internally at Google "$X is deprecated and $Y isn't ready yet", and I think that applies here, but I don't know Android UI as well as I'd like before damning it: I wrote Java + layouts for the one big UI feature I did, then was one of the first to do Kotlin, then moved to Flutter* from then on. In that vein: I cannot describe intensely enough how much I disliked Kotlin, and I get the vibe compose is not quite ready yet and isnt really moving the ball forward, as much as it's happy to be at general parity with SwiftUI. I really wish Flutter "won", it's such a beautiful and pleasant experience. Your job is a different job with hot reload. * Note: that was very unofficial, im almost certainly the only person who did on Android who was writing flutter, and it was because I ended up doing design system heavy work where having a web app to show designers things became paramount, no one was expecting much work on Android proper from me
hgs3 3y ago
> memory allocation takes a ton of time Depends how you define "a ton of time". Good general purpose memory allocation algorithms, like the TLSF algorithm [1], guarantee a O(1) bounded response time suitable for real-time use. To your example however, if someone introduces extra computation into math-heavy hot-looping code, then that is just sloppy development as their adding extra computation. That extra computation being memory allocation is tangential. [1] https://www.researchgate.net/publication/4080369_TLSF_A_new_dynamic_memory_allocator_for_real-time_systems https://www.researchgate.net/publication/4080369_TLSF_A_new_...
- refulgentis 3y ago
  In this context, it's not tangential, it's core. I described observing programmers I've worked with struggled to understand that memory allocation could *ever* have a significant computation cost.

pjmlp 3y ago

> Android does garbage collection and Android is slower than iOS Thing is, not only has Android runtime witness several JIT and GC refactorings since Darwin was created, originally worse than Sony and Nokia's J2ME implementations regardless of Google's marketing otherwise, there are so many factors contributing to Android's perceived slowness from bad coded UIs, sloppy programing, cheapstakes OEMs with low performance chips, and so on. On the other hand on iOS side, due to lack of GC and OS paging, when memory goes bad, applications just die.

toast0 3y ago

> Android does garbage collection and Android is slower than iOS There's a lot of things going on that make this the case. Android was built with unrestrained multitasking; there's a lot of restraint now, but there's probably still a ton of stuff going on from unrelated processes while your foreground app is chugging along. iOS locks down background execution, and I suspect system apps have limited background execution as well. Less task switching and less cache pollution help a lot. iOS only runs on premium phones. Even Apple's lower priced phones are premium phones. Android isn't necessarily quick on premium phones, but it can be much worse on phones designed to a $50 price point. IMHO, A large issue is that the official UI toolkits are terribly slow. I'm more of a backend person, but I put together a terrible weather app, and first paint is very slow, even though it starts with placeholder data (or serialized data from a previous run); using an HTML view was much faster because it only makes one toolkit objeft and more capable because css layout lets you wrap text around an image nicely. Maybe there's some trick I'm not aware of to make 'native ui' not terrible on Android... but that experience helped me understand why everything is so slow to start.

mst 3y ago
If it's slower than a webview, I strongly suspect you're holding it wrong. However "if you do it the naive/obvious way, it performs this badly" is not a good property of a system and still probably explains why so many things are dog slow to get going. (I doubt I'd do any better than you did myself, mind, I'm pretty sure I have even less idea what I'm doing on android than you do) I'd be willing to bet the price of a pint that if either of us flailed around on iOS instead we'd probably end up with much better startup time even hardware-for-hardware because the easiest path for us to flail down is probably much saner than the equivalent on android. (insert rant about APIs needing to make sure the natural path that a newbie takes is also a path that produces -good- results even if they'll still need to git gud to achieve -excellent- results)
- toast0 3y ago
  > If it's slower than a webview, I strongly suspect you're holding it wrong. I sincerely hope you're right. But I was following the path as best I could, so I'm just not sure how it could have gone so wrong. I do 100% agree with your assessment of my flailing though. ;) It wasn't the only source of frustration (the weather API I was using looked good, but is actually crap, and their support blew me off when I pointed out data inconsistencies, so that's ugh). So it was easy to discard. Back to weather prediction by induction.
  - refulgentis 3y ago
    I was an iOS dev for 7 years before G, then iOS app for Android watches for a year or two, then Android proper for...4 years? 100% cosign on the UI toolkit being.......ugh. There's a general saying internally at Google "$X is deprecated and $Y isn't ready yet", and I think that applies here, but I don't know Android UI as well as I'd like before damning it: I wrote Java + layouts for the one big UI feature I did, then was one of the first to do Kotlin, then moved to Flutter* from then on. In that vein: I cannot describe intensely enough how much I disliked Kotlin, and I get the vibe compose is not quite ready yet and isnt really moving the ball forward, as much as it's happy to be at general parity with SwiftUI. I really wish Flutter "won", it's such a beautiful and pleasant experience. Your job is a different job with hot reload. * Note: that was very unofficial, im almost certainly the only person who did on Android who was writing flutter, and it was because I ended up doing design system heavy work where having a web app to show designers things became paramount, no one was expecting much work on Android proper from me

hgs3 3y ago

> memory allocation takes a ton of time Depends how you define "a ton of time". Good general purpose memory allocation algorithms, like the TLSF algorithm [1], guarantee a O(1) bounded response time suitable for real-time use. To your example however, if someone introduces extra computation into math-heavy hot-looping code, then that is just sloppy development as their adding extra computation. That extra computation being memory allocation is tangential. [1] https://www.researchgate.net/publication/4080369_TLSF_A_new_dynamic_memory_allocator_for_real-time_systems https://www.researchgate.net/publication/4080369_TLSF_A_new_...

refulgentis 3y ago
In this context, it's not tangential, it's core. I described observing programmers I've worked with struggled to understand that memory allocation could *ever* have a significant computation cost.