Former Sun Mobile JIT Engineers Take On Mobile JavaScript/HTML Performance 106
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?"
Garbage Collection is not O(GC)=0 (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.
Re:I blame the DOM too (Score:4, 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.
Looking at the generated assembly code (Score:3, 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.