Jonas Sicking wrote:
Jean-Yves Bitterlich wrote:
A few alternatives were proposed here, referred below as
(i) 'attribute NodeList childElements',
(ii) 'Node item(index)' and
(iii) xpath .querySelector.
I personally like (iii) because it is powerful (or is it just queries
that are powerful?), however it definitely belongs to another spec.
Alternative (i) has its advantages and disadvantages that were also
theoretically mentioned in this thread. However, from our experience
in the mobile space and in particular given our implementations
(optimized SVG and 280-DOM, both for Java-ME), it would cost extra
memory and code execution: the implementation would need to create an
object with very short life span (an instance of NodeList). It should
hurt the performance on two fronts: extra garbage collection and extra
code execution. On the other hand, if Elements would cache the
NodeList object it will inevitably affect RAM footprint.
Do you have any data on how much extra this footprint would be? It seems
to me that it usually should be very small compared to the other things
stored in a DOM, such as attribute values and text nodes, not to mention
all rendering objects needed to display a web page.
/ Jonas
Answer from our implementation team
---
Attribute values and text node data are user data, so it is out
of our equation. The remaining is what we spend on keeping the
user data organized. JSR280 targets devices with RAM in a range
of a few hundred kilobytes (possible even several tenth of
kilobytes). An addition of a single integer to each element node
multiplied by, say, a hundred nodes would consume noticeable
percentage of RAM.
And, after all, web page is only one possible application of DOM.
Misha
---