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

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

Received on Thursday, 10 April 2008 06:23:26 UTC