Jean-Yves Bitterlich wrote:
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
---
I don't understand how you can simply ignore large parts of the data you
need to store in the DOM, i.e. the user data. Sure, this new object
could be a "noticeable percentage" of the remainder, but it's a
noticeable percentage of just a percentage of all needed data.
Also, if you are constrained on memory, surely you are storing the
child-list as an array in the parent, rather than as
next/previousSibling pointers in all the children as that would consume
more data. In this case it would be a performance hit if the only way to
iterate the list of child elements were through
.next/.previousElementSibling properties?
/ Jonas
