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?"

3 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.

  2. 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.

  3. 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.