Re: [Element Traversal LC] access to element by index

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

Received on Thursday, 10 April 2008 08:11:23 UTC