7 ms·

> Despite how fast Tegra X1 is, and the fact that the SoC is seemingly always using its A57 cores, the interface can be quite janky at times. Normally things p

> Despite how fast Tegra X1 is, and the fact that the SoC is seemingly always using its A57 cores, the interface can be quite janky at times. Normally things perform fine, but both Josh and I have observed random lag and frame drops when doing basic actions like scrolling, opening apps, and bringing down the notification drawer. This is aggravating to no end. Top of the line (mobile) hardware, years and millions of dollars in engineering effort, and perf still sucks. I've tried very hard for years to be charitable about this problem: programming is hard, and there are a lot of smart people working on this. But something is fundamentally broken with Android's abstractions. I don't know enough about Android's architecture to say what it is -- but there is no other reason for perf to still be a problem [1]. Every Android device I've owned has had these issues, while my $45 Nokia Lumia Windows phone has been consistently responsive for over two years, on marginal hardware. What the hell is going on here? [1] Either that, or critical code paths are being bloated with unnecessary features faster than the runtime and hardware are improving. Which would still be surprising, because that has to be a lot of bloat.

astn 11y ago
Java.
- userbinator 11y ago
  That's the short answer, but to elaborate, it probably has more to do with the culture surrounding the language than the overhead of the JVM, although that also plays a role. What I mean by "culture" is the widespread notion (cargo-cult?) among Java programmers that adding more classes and abstraction is always better, almost like a "best practice", leading to "enterprise" monstrosities with deep inheritance hierarchies and ridiculous amounts of indirection to accomplish the simplest of tasks. The low consideration given to memory management in general (there's a GC, but that doesn't mean you should abandon all thought about memory allocation --- an analogy I like to use is how it's possible to get as good fuel economy with an automatic transmission as a manual, with the right technique) also contributes to the bloat. The JVM itself has a certain amount of unavoidable overhead, but even if it was e.g. 10x slower than native code at best, I don't think that's the main problem. I've used systems that were more than 10x slower in benchmark-terms and had less than 1/10th the memory, yet felt much more responsive and performant. The problem is the culture that encourages this massive resource waste and selfish conservation of developer's time --- at the expense of everyone else.
  - astn 11y ago
    >The JVM itself has a certain amount of unavoidable overhead That is not a "certain amount of overhead" but the inherent incompatility with the modern hardware. With Java writing cache-friendly code is extremely difficult: boxing and indirections are encouraged while primitive types are cumbersome and value types are possible only through the direct byte manipulation. Memory overhead is enourmous. A simple collection like a hashmap of short strings can have up to a 75% overhead.
- jallmann 11y ago
  Didn't want to say it outright, but that's my theory too. Having a VM manage everything in a resource/power constrained environment is a crazy idea in the first place. Oracle's JVM is competitive because of heroic engineering, in spite of Java's design -- not because of it. And it still has tradeoffs, like insane memory usage. ART/Dalvik are operating under different constraints, which probably contributes significantly to Android's handicap. That can't be the whole story though, because C# and VB.NET both (seem to) perform decently under a managed runtime on Windows Phone. Wonder how big of a role the CLR has in typical WP apps and the WP core, as opposed to unmanaged C/C++ code.
  - dilap 11y ago
    c# has value types right?
  - pjmlp 11y ago
    .NET is AOT compiled to native code since Windows Phone 8. On Windows Phone 8.x, it uses MDIL (Machine Dependent Intermediate Language) meaning native code with symbolic names for the on-device linker. On Windows Phone 10 onwards, it makes use of .NET Native. Both are based on Visual C++'s backend, which is way more world battle tested than ART. .NET also supports value types. Also the XAML layouts are compiled to binay, not interpreted on load like on Android (aka inflated). Windows Phone also only supports asynchronous code, graphics and sound APIs must be hardware accelerated.
    - iofj 11y ago
      The Go authors had a pretty good article on what's wrong with Java's performance : pointers everywhere. Every last little thing that isn't a primitive type is a pointer. Everywhere, in every bit of code. That means a "new Object()" takes up 16 bytes (8 bytes for the object, 8 for the pointer to it). That means you fill a cache line by allocating 4 objects, or 2 objects containing a single reference, or ... So in java you should never program a line drawing loop by using 2 vectors, because 2 vectors, each with 2 32-bit ints take up 82 (2 pointers to the objects you're using) + 82 (overhead for the objects) + 4*2 (the actual data) 40 bytes of data. No way you can fit that in registers and still use registers to actually calculate things. So instead you should use 4 ints and just forget about the objects, and even that will only work if you never call any functions. Same loop in C/C++/Pascal/Go/... using structs takes 8 bytes (they don't keep structs on the heap), which, if necessary, fits in 1 register (granted, in practice we're talking 2 registers, but still). People might reply to this with benchmarks, but if you actually analyse the java code where java beats or is comparable with C/C++ you're going to see zero object allocations. You're not even going to see them using bool in the extreme cases, rather they'll bitshift into ints to effectively generate packed bools (certainly in SAT benchmarks). This is not realistic java code, which would have been way slower. Java's memory model is the main culprit at this point in time. Java can do incredible tricks with programs, and actually exposes them, enabling lots of language creativity on the JVM. But there's a pretty sizeable cost in speed and memory usage.
- pjmlp 11y ago
  And Windows Phone has .NET. The problem is that Dalvik never had a GC and JIT support that could compare with other implementations. Even ART seems to still have lots of optimization opportunities to explore.
  - j3116294 11y ago
    Dalvik is so terrible even v8 outperforms it.
- on_and_off 11y ago
  if it was that easy, google would have moved away from java years ago...
  - pjmlp 11y ago
    From their Google IO presentations and their atitude towards NDK users vs how other mobile tems deal with their devs, I would say Java runs strong within who calls the shots at the Android's team. Even if some of the code looks like written by devs recovering from years of exposition to hungarian notation.
    - on_and_off 11y ago
      The NDK is not part of their priorities indeed (although to be fair it seems that things are slowly getting better with a team dedicated to integrating Clion). They are smart engineers though and I have no doubt that if C++ had been the best choice for the platform, we would not be writing apps in java ... tbh, I am really tired of the simplistic 'because java' argument with nothing to back it up ... I have no love for the language (although I think it gets more flak than it deserves) but I have spent a lot of time working on the performances of Android apps and none of the issues I have fixed would have been any different in another language.
      - pjmlp 11y ago
        I would also used Java if Oracle hadn't dropped the ball in mobile support, as if they couldn't provide JIT and AOT compilers. So given that I enjoy C++, when conding on my own, that is what I end up using for hobby coding between mobile platforms. But the NDK and JNI wrapping take the fun out of it.
        on_and_off 11y ago
        I am curious : on what kind of mobile apps are you working on your free time ? By design, the NDK can only access a very small part of the platform APIs. It is not an issue if you are making something where you are supposed to use the NDK (like a drawing app or a game), but for a 'traditional' app, that's another matter.
Yhippa 11y ago
I love Android but I really agree with this statement regarding responsiveness. Unfortunately I see this the most when using the Android Camera app. It just randomly lags now, causing me to miss special moments. I have no idea what is going on. I've searched all the corners of the internet and there's no good way to troubleshoot this.
jordanthoms 11y ago
Completely agree - I'm an Android fan, but it is unbelievable that the performance is still such an issue. Even the Nexus 6P drops frames quite regularly, and that's even with it doing much simpler animations than is common on iOS. You can see this with the Material Design specs as well - the rendered demo videos (e.g. https://www.youtube.com/watch?v=Q8TXgCzxEnw https://www.youtube.com/watch?v=Q8TXgCzxEnw ) from the Design team are amazing, but what's actually been implemented on Android is far less sophisticated and even then they frequently skip frames. Interestingly, many of the Google apps are much closer to the Design specs and perform better on iOS and even on the web, at least in Chrome. Hopefully this will finally be resolved with the Chrome OS merge (Chrome OS has great performance) - It must be extremely frustrating for the Google Design teams when they can't implement their designs properly on their own platform.
pjmlp 11y ago
Yes, my Lumia 630 is faster than most Android devices priced around 200€ and below. One problem with Android is that they went software rendering since the early days, and even with all the changes to hardware rendering, there are code paths that will trigger software rendering. Now they started advertising Android M should have proper audio support, but it doesn't seem like it. Even with ART, it appears that compilation to native code still needs to improve a lot. iOS and WP have much more care in native code performance, hardware rendering and real time audio support. Then by making use of programming languages with support for value types, they require way less memory than Android devices. Apparently it is better to spend resources playing IDE and build tools migrations.
rasz_pl 11y ago
isnt Android UI single thread with global lock?
- on_and_off 11y ago
  it uses a RenderThread now.
- kllrnohj 11y ago
  single thread yes (just like every UI toolkit...) but there is not and never was a global lock.
agumonkey 11y ago
Also different mindset in terms of UX. These are web spirited devices. Material design was like a CSS3.5 demo. Android 4.4 was still lean in terms of usage[1], Material is eye candy but has zero value on in-the-street interactions. Also, how much of the performance grade is due to the reviewer ? I see people saying 'one need at least <2013> hardware ...' as if people couldn't do anything before. Coming from someone on a 2007 laptop .. I wonder how much social relativity plays here. [1] When I boot an old 4.4 phone, I feel relieved to see simple centered gray/blue menus, even after a year of Lollypop 'training'.
on_and_off 11y ago
Tablets are hard. The SOCs are not that much better than the ones used for phones (when they are not just the same) but they have way more pixels to carry around. >But something is fundamentally broken with Android's abstractions I think that the core problem is that Android has been built to be a multi process OS at its core with little regards for UI perfs. Things have been moving in the right direction since at least Android 4.0, but it seems that there is a lot of space to cover. Android has just got a RenderThread with Lollipop IIRC, iOS had one from day one.

astn 11y ago

Java.

userbinator 11y ago
That's the short answer, but to elaborate, it probably has more to do with the culture surrounding the language than the overhead of the JVM, although that also plays a role. What I mean by "culture" is the widespread notion (cargo-cult?) among Java programmers that adding more classes and abstraction is always better, almost like a "best practice", leading to "enterprise" monstrosities with deep inheritance hierarchies and ridiculous amounts of indirection to accomplish the simplest of tasks. The low consideration given to memory management in general (there's a GC, but that doesn't mean you should abandon all thought about memory allocation --- an analogy I like to use is how it's possible to get as good fuel economy with an automatic transmission as a manual, with the right technique) also contributes to the bloat. The JVM itself has a certain amount of unavoidable overhead, but even if it was e.g. 10x slower than native code at best, I don't think that's the main problem. I've used systems that were more than 10x slower in benchmark-terms and had less than 1/10th the memory, yet felt much more responsive and performant. The problem is the culture that encourages this massive resource waste and selfish conservation of developer's time --- at the expense of everyone else.
- astn 11y ago
  >The JVM itself has a certain amount of unavoidable overhead That is not a "certain amount of overhead" but the inherent incompatility with the modern hardware. With Java writing cache-friendly code is extremely difficult: boxing and indirections are encouraged while primitive types are cumbersome and value types are possible only through the direct byte manipulation. Memory overhead is enourmous. A simple collection like a hashmap of short strings can have up to a 75% overhead.
jallmann 11y ago
Didn't want to say it outright, but that's my theory too. Having a VM manage everything in a resource/power constrained environment is a crazy idea in the first place. Oracle's JVM is competitive because of heroic engineering, in spite of Java's design -- not because of it. And it still has tradeoffs, like insane memory usage. ART/Dalvik are operating under different constraints, which probably contributes significantly to Android's handicap. That can't be the whole story though, because C# and VB.NET both (seem to) perform decently under a managed runtime on Windows Phone. Wonder how big of a role the CLR has in typical WP apps and the WP core, as opposed to unmanaged C/C++ code.
- dilap 11y ago
  c# has value types right?
- pjmlp 11y ago
  .NET is AOT compiled to native code since Windows Phone 8. On Windows Phone 8.x, it uses MDIL (Machine Dependent Intermediate Language) meaning native code with symbolic names for the on-device linker. On Windows Phone 10 onwards, it makes use of .NET Native. Both are based on Visual C++'s backend, which is way more world battle tested than ART. .NET also supports value types. Also the XAML layouts are compiled to binay, not interpreted on load like on Android (aka inflated). Windows Phone also only supports asynchronous code, graphics and sound APIs must be hardware accelerated.
  - iofj 11y ago
    The Go authors had a pretty good article on what's wrong with Java's performance : pointers everywhere. Every last little thing that isn't a primitive type is a pointer. Everywhere, in every bit of code. That means a "new Object()" takes up 16 bytes (8 bytes for the object, 8 for the pointer to it). That means you fill a cache line by allocating 4 objects, or 2 objects containing a single reference, or ... So in java you should never program a line drawing loop by using 2 vectors, because 2 vectors, each with 2 32-bit ints take up 82 (2 pointers to the objects you're using) + 82 (overhead for the objects) + 4*2 (the actual data) 40 bytes of data. No way you can fit that in registers and still use registers to actually calculate things. So instead you should use 4 ints and just forget about the objects, and even that will only work if you never call any functions. Same loop in C/C++/Pascal/Go/... using structs takes 8 bytes (they don't keep structs on the heap), which, if necessary, fits in 1 register (granted, in practice we're talking 2 registers, but still). People might reply to this with benchmarks, but if you actually analyse the java code where java beats or is comparable with C/C++ you're going to see zero object allocations. You're not even going to see them using bool in the extreme cases, rather they'll bitshift into ints to effectively generate packed bools (certainly in SAT benchmarks). This is not realistic java code, which would have been way slower. Java's memory model is the main culprit at this point in time. Java can do incredible tricks with programs, and actually exposes them, enabling lots of language creativity on the JVM. But there's a pretty sizeable cost in speed and memory usage.
pjmlp 11y ago
And Windows Phone has .NET. The problem is that Dalvik never had a GC and JIT support that could compare with other implementations. Even ART seems to still have lots of optimization opportunities to explore.
- j3116294 11y ago
  Dalvik is so terrible even v8 outperforms it.
on_and_off 11y ago
if it was that easy, google would have moved away from java years ago...
- pjmlp 11y ago
  From their Google IO presentations and their atitude towards NDK users vs how other mobile tems deal with their devs, I would say Java runs strong within who calls the shots at the Android's team. Even if some of the code looks like written by devs recovering from years of exposition to hungarian notation.
  - on_and_off 11y ago
    The NDK is not part of their priorities indeed (although to be fair it seems that things are slowly getting better with a team dedicated to integrating Clion). They are smart engineers though and I have no doubt that if C++ had been the best choice for the platform, we would not be writing apps in java ... tbh, I am really tired of the simplistic 'because java' argument with nothing to back it up ... I have no love for the language (although I think it gets more flak than it deserves) but I have spent a lot of time working on the performances of Android apps and none of the issues I have fixed would have been any different in another language.
    - pjmlp 11y ago
      I would also used Java if Oracle hadn't dropped the ball in mobile support, as if they couldn't provide JIT and AOT compilers. So given that I enjoy C++, when conding on my own, that is what I end up using for hobby coding between mobile platforms. But the NDK and JNI wrapping take the fun out of it.
      - on_and_off 11y ago
        I am curious : on what kind of mobile apps are you working on your free time ? By design, the NDK can only access a very small part of the platform APIs. It is not an issue if you are making something where you are supposed to use the NDK (like a drawing app or a game), but for a 'traditional' app, that's another matter.

Yhippa 11y ago

I love Android but I really agree with this statement regarding responsiveness. Unfortunately I see this the most when using the Android Camera app. It just randomly lags now, causing me to miss special moments. I have no idea what is going on. I've searched all the corners of the internet and there's no good way to troubleshoot this.

jordanthoms 11y ago

Completely agree - I'm an Android fan, but it is unbelievable that the performance is still such an issue. Even the Nexus 6P drops frames quite regularly, and that's even with it doing much simpler animations than is common on iOS. You can see this with the Material Design specs as well - the rendered demo videos (e.g. https://www.youtube.com/watch?v=Q8TXgCzxEnw https://www.youtube.com/watch?v=Q8TXgCzxEnw ) from the Design team are amazing, but what's actually been implemented on Android is far less sophisticated and even then they frequently skip frames. Interestingly, many of the Google apps are much closer to the Design specs and perform better on iOS and even on the web, at least in Chrome. Hopefully this will finally be resolved with the Chrome OS merge (Chrome OS has great performance) - It must be extremely frustrating for the Google Design teams when they can't implement their designs properly on their own platform.

pjmlp 11y ago

Yes, my Lumia 630 is faster than most Android devices priced around 200€ and below. One problem with Android is that they went software rendering since the early days, and even with all the changes to hardware rendering, there are code paths that will trigger software rendering. Now they started advertising Android M should have proper audio support, but it doesn't seem like it. Even with ART, it appears that compilation to native code still needs to improve a lot. iOS and WP have much more care in native code performance, hardware rendering and real time audio support. Then by making use of programming languages with support for value types, they require way less memory than Android devices. Apparently it is better to spend resources playing IDE and build tools migrations.

rasz_pl 11y ago

isnt Android UI single thread with global lock?

on_and_off 11y ago
it uses a RenderThread now.
kllrnohj 11y ago
single thread yes (just like every UI toolkit...) but there is not and never was a global lock.

agumonkey 11y ago

Also different mindset in terms of UX. These are web spirited devices. Material design was like a CSS3.5 demo. Android 4.4 was still lean in terms of usage[1], Material is eye candy but has zero value on in-the-street interactions. Also, how much of the performance grade is due to the reviewer ? I see people saying 'one need at least <2013> hardware ...' as if people couldn't do anything before. Coming from someone on a 2007 laptop .. I wonder how much social relativity plays here. [1] When I boot an old 4.4 phone, I feel relieved to see simple centered gray/blue menus, even after a year of Lollypop 'training'.

on_and_off 11y ago

Tablets are hard. The SOCs are not that much better than the ones used for phones (when they are not just the same) but they have way more pixels to carry around. >But something is fundamentally broken with Android's abstractions I think that the core problem is that Android has been built to be a multi process OS at its core with little regards for UI perfs. Things have been moving in the right direction since at least Android 4.0, but it seems that there is a lot of space to cover. Android has just got a RenderThread with Lollipop IIRC, iOS had one from day one.