Slashdot Mirror

← Back to Stories (view on slashdot.org)

Former Sun Mobile JIT Engineers Take On Mobile JavaScript/HTML Performance

Posted by samzenpus on from the point-counterpoint dept.

First time accepted submitter digiti writes "In response to Drew Crawford's article about JavaScript performance, Shai Almog wrote a piece providing a different interpretation for the performance costs (summary: it's the DOM not the script). He then gives several examples of where mobile Java performs really well on memory constrained devices. Where do you stand in the debate?"

26 of 106 comments (clear)

  1. I blame the DOM too by Anonymous Coward · · Score: 5, Interesting

    An arbitrary tree of arbitrary objects with arbitrary methods of manipulating them thanks to years of incremental changes that are never properly documented (quick! point to the document showing that a select tag has a value attribute!) and are never deprecated.

    1. Re:I blame the DOM too by pspahn · · Score: 3, Informative

      quick! point to the document showing that a select tag has a value attribute!

      I'm not sure what you're looking for here. Are you saying that having a value attribute on a select element is something that is simply undocumented but valid?

      Or, are you saying that this is a deprecated attribute still found in the wild and there is no doc to explain this?

      Certainly invalid attributes are going to add some overhead to the DOM, but I don't think that's necessarily the reason a sluggish UI can be blamed on the DOM. I would imagine that a simple DOM with ten elements, each element with ten attributes would still be faster than a DOM with 100 elements, each with one attribute. Of course, this largely depends on what you're going to be doing with the elements and the attributes, but in the case of simple UI updates to the DOM, the elements are going to change more often than all of the attributes. You might update a couple attributes here and there, but the rest of the attributes are probably left as they were since they are likely unrelated to whatever UI update you are performing.

      --
      Someone flopped a steamer in the gene pool.
    2. Re:I blame the DOM too by phantomfive · · Score: 3

      What does your comment have to do with performance? The DOM has some awkward parts, certainly; and more annoying it has cross-platform incompatibilities.

      But what does that have to do with performance? How would documenting the value attribute of the select tag make things run faster?

      --
      "First they came for the slanderers and i said nothing."
    3. Re:I blame the DOM too by maxwell+demon · · Score: 5, Funny

      (quick! point to the document showing that a select tag has a value attribute!)

      Here it is.

      --
      The Tao of math: The numbers you can count are not the real numbers.
    4. Re:I blame the DOM too by Livius · · Score: 2

      How about video and flashy graphics that add no information? Or very complex layouts that get text exactly the way the designer intended and which look horrible on any screen not the target size?

      By bloat I mean clutter, not speed.

  2. Garbage Collection is not O(GC)=0 by Anonymous Coward · · Score: 3, Informative

    I think Drew's article wasn't that performance had to suffer, it was that garbage collection isn't free. It has to take place, though, so it's not an O(GC)=0 component. If garbage collection takes place in a lot of memory, but not -enough- memory, it takes a very long time, in real time. Depending heavily on the application, it may be very visible at the UI level.

    Programmers intent on using all of the resources available, and performing intensive tasks, should think about means other than garbage collection.

    1. Re: Garbage Collection is not O(GC)=0 by binarylarry · · Score: 2

      Properly written Android apps are pretty snappy and they're written in Java.

      Granted they run on a different kind of virtual machine but overall it's still pretty similar to the Java runtime.

      --
      Mod me down, my New Earth Global Warmingist friends!
    2. Re:Garbage Collection is not O(GC)=0 by Anubis+IV · · Score: 3, Interesting

      That's not the only issue with his statements about garbage collection.

      Drew made an argument that garbage collection on mobile performs poorly due to memory constraints on the platform. Almog countered by pointing out that Drew used a desktop garbage collector rather than a mobile garbage collector, which is important, since mobile garbage collectors are more aggressive at cleaning up stuff like unused paths from JIT, meaning that they make better use of their available memory. Almog was quick to note that being more aggressive also means that the garbage collector performs worse than its desktop counterpart.

      Stop and re-read that last sentence, because if I'm understanding this correctly, Almog is basically making the argument that we can avoid the memory concerns Drew brought up -- concerns which were only brought up to explain why there are performance issues -- by using a garbage collector that performs worse.

      It's possible, I suppose, that the performance hit from being more aggressive is less severe than the performance hit from running up against the limitations of memory more often, but if that's the case, Almog really should have said so, since right now it sounds like he's completely undermining his own point.

    3. Re: Garbage Collection is not O(GC)=0 by Rockoon · · Score: 2

      only if by 'properly written' you mean 'doesnt use anywhere near all of the available memory'

      --
      "His name was James Damore."
  3. No rebuttal by arendjr · · Score: 5, Interesting

    While this post is a valuable addition to Drew's analysis, I feel it's not really a rebutal at all.

    Yes, JavaScript is slow for the reasons Drew mentioned and yes, the DOM is a nightmare to optimize for responsive UIs. They're both right.

    While this blog also provides some nice insight into how you can have acceptable performance with a GC on mobile, it's not offering any workable alternative that would work for JavaScript. So Drew's article still comes out pretty strong, IMO.

    1. Re:No rebuttal by gl4ss · · Score: 4, Interesting

      I'm just blabberfastebasted about the summary.

      first it goes on about javascript and then about mobile java performing really well on some devices.
      j2me - commonly known as mobile java, being something entirely different from javascript.. and j2me did pretty well. you could do wolfenstein clones in 128kbytes(was a common .jar size limit, earlier than that 64kbytes was pretty common) on machines with ~300-400kbytes of ram available for you.. and gc worked just fine, so long as you didn't abuse String or do shit like that - but that's a bit easier to code for in java than in javascript imho(reusing objects etc).

      dom though.. of course, it's ridiculous to use for high responsive stuff, while javascript itself can run pretty nicely, lacking real threads certainly doesn't help etc of course.. but it's pretty obvious how you can do things with canvas that would bog the dom renderer.

      the article is about how javascript on mobile should be doable ok because j2me worked remarkably well? since j2me did work remarkably well on the lower level(really, it did). what did not work out was their api jsr process for j2me which zombied the whole platform and made almost all extensions useless or half useless - had they not fucked it up like that we would not have needed android.

      funny thing about j2me is that most of the mobile stuff I have coded over last 10 years is such that you cannot go to a shop now and buy a device that would run them - except for the j2me code, I could still buy a cheapo nokia and run them.

      --
      world was created 5 seconds before this post as it is.
    2. Re:No rebuttal by slacka · · Score: 4, Interesting

      While this post is a valuable addition to Drew's analysis, I feel it's not really a rebutal at all.

      Yes, JavaScript is slow for the reasons Drew mentioned and yes, the DOM is a nightmare to optimize for responsive UIs. They're both right.

      The key issue here is that these web technologies are being shoehorned into areas they were never designed for. From Document Object Model being used for Applications to the lightweight scripting language, JavaScript, being used for heavy weight programming of course the end result is going to be a poor mobile experience.

      If W3C and WHATWG seriously want to compete with Android and iOS Apps, they should consider throwing out the DOM and CSS standards and starting over. JavaScript can be fixed, but DOM/CSS are so technically flawed to the core, the sooner they're depreciated, the sooner the web has a real chance as being a generic platform for applications.

  4. Perceived Performance by Hamfist · · Score: 4, Insightful

    I dislike the separation of 'Perceived' vs 'Actual' performance. If I perceive it to be slow, it's slow. This reminds of of the Firefox devs that spent years saying how if an add-on makes their browser a memory hog and a slowpoke, it's not their problem because their performance is fine.

    Devs.. If it's slow, it's slow. Call it perceived, call it actual, call it the Pope for all I care. It's a Slow Pope.

  5. Data vs Hand-waving by 2megs · · Score: 5, Insightful

    Crawford brought in lots of data on real-world performance. (e.g. http://sealedabstract.com/wp-content/uploads/2013/05/Screen-Shot-2013-05-14-at-10.15.29-PM.png)

    Almog's rebuttal has a lot of claims with no actual evidence. Nothing is measured; everything he says is based on how he thinks things should in theory work. But the "sufficiently smart GC" is as big a joke as the "sufficiently smart compiler", and he even says "while some of these allocation patterns were discussed by teams when I was at Sun I don't know if these were actually implemented".

    Also:

    (in fact game programmers NEVER allocate during game level execution)....This isn't really hard, you just make sure that while you are performing an animation or within a game level you don't make any allocations.

    I'm a professional game programmer, and I'm laughing at this. If you're making Space Invaders, and there's a fixed board and a fixed number of invaders, that statement is true. If you're making a game for this decade, with meaningful AI, an open world that's continuously streamed in and out of memory, and dynamic, emergent, or player-driven events, that's just silly. For Mr. Almog to even say that shows how much he doesn't know about the subject.

  6. Throughput, latency, and latency hiding by tepples · · Score: 4, Interesting

    Perhaps it's a difference between throughput and latency. Nine moms can make nine babies in nine months, offering nine times the throughput of one mom, but each baby still takes nine months from conception to completion. Users tend to notice latency more than throughput unless an operation already takes long enough to need a progress bar. Some algorithms have a tradeoff between throughput and latency, which need fine tuning to make things feel fast enough.

    There are also a few ways to psychologically hide latency even if you can't eliminate it. The "door opening" transition screen in Resident Evil is one example, hiding a load from disc, as are some of the transitions used by online photo albums to slowly open a viewer window while the photo downloads.

    1. Re:Throughput, latency, and latency hiding by aliquis · · Score: 4, Funny

      Or you sit there like:

      "Stupid animation just show me the content."

  7. Looking at the generated assembly code by tepples · · Score: 2, Informative

    If they care about performance why not use assembly?

    Some people do (in a sense) use assembly when they use C. If a particular inner loop is running too slowly, an expert programmer might look at the code that the compiler generates to see what's going wrong. For example, an inefficient translation of C to assembly language might point to needing const or restrict qualifiers to allow the compiler to make certain optimizations.

  8. My guarantee by sl4shd0rk · · Score: 2

    I guarantee Javascript will perform much better once we get to 16 cores and 3.6Ghz on the standard mobile device.

    --
    Join the Slashcott! Feb 10 thru Feb 17!
    1. Re:My guarantee by i+kan+reed · · Score: 4, Funny

      For the 3 seconds before your battery runs out.

    2. Re:My guarantee by phantomfive · · Score: 2

      One of the points of the original article (linked to in the summary) is that we aren't going to get to 16 cores and 3.6 Ghz on the standard mobile device any time soon. There aren't many desktops that have that kind of processor.......

      --
      "First they came for the slanderers and i said nothing."
  9. Re:friggen dummies... by angel'o'sphere · · Score: 2

    1) You need 100 times more time to program a certain program if you do it in assembly
    2) You need X times the time if you want it running on X platforms (can even be the same processor)

    A long known fact in programming is: your programmers productivity in terms of lines of code per day is FIXED. REGARDLESS of language.
    That simply means a programmer who is able to "correctly" write 25 - 50 lines of Java per day will also only write like 25 - 50 lines assembly per day.

    This is the main reason why we migrated from bytecode/machine code to assembly and from there to MACRO ASSEMBLERS and from there to Fortran/Cobol and from there to Lisp/SmallTalk.

    Then came the many mixed in solutions like C (a portable assembler) / PL1 / ALgol / Pascla /Java etc.

    Higher abstraction levels make it possible that programmers are 100 even up to 1000 times faster than our grandfathers with assembly.

    --
    Cost free eBook I read (by iBook/Kobo/Amazon/ObookO/Gutenberg etc.): "The Green Odyssey" by Philip Jose Farmer.
  10. I didn't post a rebuttal by Shai+Almog · · Score: 5, Interesting

    I actually agree with almost everything Drew wrote with the exception of his GC statements, I worked for an EA contractor in the 90's doing large scale terrain streaming on what today would be a a computer less powerful than an iPhone so while my game programming experience might be outdated its still valid. Saying that I don't know if its actually implemented only referred to the last section. Like I said, I actually worked on the VM code as well as the elements on top of it. As I said in the comments to the article never might have been harsh but I pretty much stand by it. If you use a GC you need to program with that in mind and design the times where GC occurs (level loading). Most of your dynamic memory would be textures anyway which are outside the domain of the GC altogether and shouldn't trigger GC activity. To avoid overhead in a very large or infinite world you swap objects in place by using a pool, no its not ideal and you do need to program "around" the GC in that regard. OTOH when we programmed games in C++ we did exactly the same thing, no one would EVER allocate dynamic memory during gameplay to avoid framerate cost.

    1. Re:I didn't post a rebuttal by IamTheRealMike · · Score: 2, Interesting

      FYI stack allocation (the optimisation you refer to) is implemented in the JVM for some time already. It is capable of eliminating large numbers of allocations entirely on hot paths. Of course, there is a lot of memory overhead to all of this - the JVM has to do an escape analysis and it has to keep around bookkeeping data to let it unoptimize things.

      For some reason they call this optimisation scalar replacement. I'm not sure why. In theory this can help close the gap a lot, because a big part of the reason GC is seen as slow is just because the languages that use it put so much pressure on the heap due to their library and language designs encouraging tons of tiny objects. If you can put them onto the stack then things can get much faster. I use some pretty large and complicated Java apps these days (like IntelliJ) and they seem to perform well, so perhaps things like this have turned the tide somewhat.

    2. Re:I didn't post a rebuttal by ras · · Score: 2

      I actually agree with almost everything Drew wrote with the exception of his GC statements

      I'm courious. Drew said two things about GC:

      • - It's slower than manual memory allocation in memory constrained environments.
      • - It's faster than manual memory allocation where there 5x or more of actual memory usage.

      He didn't say GC always introduces huge latencies, probably because given an incremental GC and enough memory it doesn't. So which of the two assertions are you disagreeing with?

      Or to put is another way, going by Drew's data if EA had lots of memory for whatever they were putting in the GC heap and their primary consideration was speed, they would have been far better off using GC.

      The biggest weakness in Drew's argument that GC is and will remain dominant cause is IMHO the assumption that a phone will always be memory constrained. We have 2G phones now. 4G can't be far away. You can hardly call 4G "memory constrained". If mobile slowness were just caused by GC, my guess is at 4G most apps will have far more than 5x their memory requirements, so GC should actually help. I'm also guessing mobile will remain slow. The trifecta that ensures this is:

      • - JavaScript is and will always remain a slow language, for the reasons Drew says.
      • - CPU speed on mobile will remain slow, again for the reasons he says, and
      • - The one thing area of improvement we are seeing in mobile, the growing in the number of cores, doesn't help JavaScript can't use because it's single threaded.
  11. The article didn't say that by digiti · · Score: 2

    It says that JavaScript is inherently slow because of DOM. It says that this should not be applied as a sweeping generalization to all managed languages e.g. Java. Then it gives examples including mobile Java performance where small heap devices work just fine.

  12. Re:friggen dummies... by Anonymous Coward · · Score: 5, Insightful

    You're wrong. But not in the way you think. The ability to write abstractions, and an obsession with design patterns, often results in needless abstraction and a loss of focus.

    Libraries like C++ STL and Java Collections only make this worse. Why? Because your application is basically one giant data structure. I forgot whether it was Dennis Ritchie, or Ken Thompson, or whomever, but it was once that said good programming is about implementing the correct data structures. Note that this doesn't mean reusing generic data structures; it means drawing upon the universe of conceptual data structures to craft a narrowly focus data structure and algorithm that fits your problem.

    If you start out with generic data structures, then you end up working backwards. You have lots of boilerplate code just to use those generic data structures, which you then aggregate and glue together in the same way you would have done from scratch, but with far less code. Programming is not about splicing hash tables together with trees ad hoc. This is a ridiculously reductive perspective on what is programming and how good programs are written.

    This is why, almost without fail, real-world applications developed in high-level languages tend to have ridiculously high source line counts. People get carried away with abstraction, including the language implementors with their plethora of generic data structure libraries.

    IME, C is *the* sweet spot, if you had to pick a single language. However, you can do better by mixing and matching different languages, especially where they offer unique characteristics--functions as first-class objects + real closures (i.e. not C++ lambdas), coroutines, exceptional optimizing support (e.g. Fortran for iterative numerical algorithms), and functional language characteristics which make is easier to express some kinds of data structures and algorithms. This is why I stay away from C++; it's too much of a pain to mix C++ with various other languages, where almost every language in existence has strong C support.

    If people spent as much time maintaing proficiency in different languages instead of trying to do everything in a single language (and grappling with the inevitably cognitive dissonance when defending their choices on web forums), then the world would be a far more efficienct and less bug-prone place.