[HN Gopher] Latest Android Runtime (ART) update led to apps star...
       ___________________________________________________________________
        
       Latest Android Runtime (ART) update led to apps starting 30% faster
        
       Author : mikece
       Score  : 68 points
       Date   : 2023-08-21 18:08 UTC (4 hours ago)
        
 (HTM) web link (9to5google.com)
 (TXT) w3m dump (9to5google.com)
        
       | cubefox wrote:
       | > _up to_ 30% on _some_ devices
       | 
       | (emphasis mine)
        
       | positr0n wrote:
       | I can't believe a 30% performance improvement has been sitting
       | there.. for 12 Android versions??
        
         | Projectiboga wrote:
         | 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.
        
         | dmitrygr wrote:
         | 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 wrote:
           | You gotta save that optimization for when performance ends up
           | on a top level OKR!
        
           | codethief wrote:
           | What's the reason it never shipped?
        
           | dimator wrote:
           | 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.
        
             | refulgentis wrote:
             | 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
        
             | dmitrygr wrote:
             | > 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 wrote:
           | Lol. All of my time at G is summed up very elegantly here.
        
         | jshier wrote:
         | 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).
        
         | wffurr wrote:
         | 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.
        
       | wffurr wrote:
       | https://android-developers.googleblog.com/2023/08/latest-art...
       | has a lot more details.
        
         | ncr100 wrote:
         | 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.
        
           | pjmlp wrote:
           | Usually that is reserved for Google IO and Android DevEx
           | talks.
           | 
           | Also the article does indeed describe some examples of what
           | was optimized.
        
             | wiseowise wrote:
             | > Google IO
             | 
             | You mean marketing party?
        
               | dcgudeman wrote:
               | why is it bad for them to market their products?
        
               | pjmlp wrote:
               | A party with several technical gems.
        
       ___________________________________________________________________
       (page generated 2023-08-21 23:01 UTC)