4 ms·

> There's no reason for a stack that is (linux kernel + > android hal + web runtime) to require more resources than > (linux kernel + android hal + dalvik and

by jlebar 12y ago

> There's no reason for a stack that is (linux kernel + > android hal + web runtime) to require more resources than > (linux kernel + android hal + dalvik and a java toolkit). Correct, but likewise there's no good reason for (linux + android hal + web) to require /less/ ram than (linux + android hal + dalvik and java toolkit). Even if we accept the claim that most of the time on Android you have both dalvik and webkit loaded at once, whereas on B2G you only have gecko running, claiming that this necessarily means that B2G uses less memory is akin to claiming that x + y > z for arbitrary values of x, y, and z, which is obviously silly. But I don't need to tell you that this claim that B2G uses less memory by design was a major frustration to me back when I owned B2G memory usage. :) If FFOS is small, it's because you and I and others worked really hard to make it so.

illumen 12y ago
Java Is anyone really surprised that Java is not so good for interactive applications? It's never been in first place for that type of app.
- icebraining 12y ago
  That's not true, the first version of Java came with Java Applets, which are interactive applications.
  - vidarh 12y ago
    Does anyone actually have good memories of the responsiveness of Applets? If anything, Applets is still to an extent responsible for a lot of the negative opinions of Java's performance and suitability for interactive applications.
    - illumen 12y ago
      The GC, and the JIT are the two main problems with Java for this use case. Both require pauses in execution, which for real time apps is a mode of failure. Also, doing things in separate threads means that scheduling of tasks also causes pauses in execution.
      - moonchrome 12y ago
        >The GC, and the JIT are the two main problems with Java for this use case. Both require pauses in execution, which for real time apps is a mode of failure. Umm, JavaScript and DOM/HTML have the exact same problem except it's magnified by the fact that the language is much more complex to JIT compile (statically typed bytecode vs dynamic/weak typed source code) and the GC has to deal with managed/native interop in the DOM. And not to mention the cost of inefficient DOM interfaces and silly data structures/native types in JS. >Also, doing things in separate threads means that scheduling of tasks also causes pauses in execution. Yea, on the order of milliseconds at worst. Unless we're talking about real time software like games which need to execute a simulation iteration 30-60 times per second (and JS is much worse for this than Java for the reasons mentioned) delays in a reasonably well implemented UI app shouldn't matter and JIT startup time can be avoided by AOT (which is much simpler for static typed languages)
        illumen 12y ago
        Best of class UI requires at least 60fps consistently, not just for games. Of course JavaScript is not great here, but this can be achieved now on the latest mobile browsers. First run time is important, and interpreters are faster in this case. Also, JavaScript can execute as it is downloaded. I can load a whole UI, and complete my task before the JVM has loaded the code. Also, at least Firefox does AOT on JavaScript now. This is how I load and start executing 1.2MB of JavaScript in 50ms in the app I'm currently producing.
        moonchrome 12y ago
        >First run time is important, and interpreters are faster in this case. ART AOT is on-install and that can even be changed to something like Mono AOT which is offline (you're essentially distributing precompiled native code along with IL) giving you the best of both worlds. >Also, at least Firefox does AOT on JavaScript now AFAIK this is only ASM.JS code, AOT compiling dynamically typed code would be questionable - maybe to avoid initial parsing costs but then you hit all of the problems of AOT (longer load time, need whole code) without the main benefit (performance gain).
  - illumen 12y ago
    Java Applets were TERRIBLE. Seriously. Native apps, and web pages were better. If you had a $30k work station with 8 times the ram of a high end PC at the time they weren't too bad.
    - icebraining 12y ago
      I'm not saying they were good. I'm saying Java was designed for that kind of applications as well.

by jlebar 12y ago

illumen 12y ago

Java Is anyone really surprised that Java is not so good for interactive applications? It's never been in first place for that type of app.

icebraining 12y ago
That's not true, the first version of Java came with Java Applets, which are interactive applications.
- vidarh 12y ago
  Does anyone actually have good memories of the responsiveness of Applets? If anything, Applets is still to an extent responsible for a lot of the negative opinions of Java's performance and suitability for interactive applications.
  - illumen 12y ago
    The GC, and the JIT are the two main problems with Java for this use case. Both require pauses in execution, which for real time apps is a mode of failure. Also, doing things in separate threads means that scheduling of tasks also causes pauses in execution.
    - moonchrome 12y ago
      >The GC, and the JIT are the two main problems with Java for this use case. Both require pauses in execution, which for real time apps is a mode of failure. Umm, JavaScript and DOM/HTML have the exact same problem except it's magnified by the fact that the language is much more complex to JIT compile (statically typed bytecode vs dynamic/weak typed source code) and the GC has to deal with managed/native interop in the DOM. And not to mention the cost of inefficient DOM interfaces and silly data structures/native types in JS. >Also, doing things in separate threads means that scheduling of tasks also causes pauses in execution. Yea, on the order of milliseconds at worst. Unless we're talking about real time software like games which need to execute a simulation iteration 30-60 times per second (and JS is much worse for this than Java for the reasons mentioned) delays in a reasonably well implemented UI app shouldn't matter and JIT startup time can be avoided by AOT (which is much simpler for static typed languages)
      - illumen 12y ago
        Best of class UI requires at least 60fps consistently, not just for games. Of course JavaScript is not great here, but this can be achieved now on the latest mobile browsers. First run time is important, and interpreters are faster in this case. Also, JavaScript can execute as it is downloaded. I can load a whole UI, and complete my task before the JVM has loaded the code. Also, at least Firefox does AOT on JavaScript now. This is how I load and start executing 1.2MB of JavaScript in 50ms in the app I'm currently producing.
        moonchrome 12y ago
        >First run time is important, and interpreters are faster in this case. ART AOT is on-install and that can even be changed to something like Mono AOT which is offline (you're essentially distributing precompiled native code along with IL) giving you the best of both worlds. >Also, at least Firefox does AOT on JavaScript now AFAIK this is only ASM.JS code, AOT compiling dynamically typed code would be questionable - maybe to avoid initial parsing costs but then you hit all of the problems of AOT (longer load time, need whole code) without the main benefit (performance gain).
- illumen 12y ago
  Java Applets were TERRIBLE. Seriously. Native apps, and web pages were better. If you had a $30k work station with 8 times the ram of a high end PC at the time they weren't too bad.
  - icebraining 12y ago
    I'm not saying they were good. I'm saying Java was designed for that kind of applications as well.