Re: [Vtd-xml-users] Random Access Proposal (take 2)

[Rodrigo C. <rn...@gm...>]

Hi!

My implementation of setPosition did a binary search for nodes, I 
think... I don't really remember well. The performance was dismal, so 
probably the implementation was wrong... ops! An efficient 
implementation would be great, althought I think depending on the 
situation using SimpleContext could still be better.

Concerning the hash end equals, yep, yor're right... but I was thinking 
perhaps in the future a pointer to the related VTDNav could be 
maintained in SimpleContext, and multiple document mixing in the same 
data structure could be possible... but yeah, I think we could change 
it, despite that new implementation only being consistent in the context 
of a single VTDNav. That specifically  should be put in the 
documentation, of course. Ok, let't keep it simple since class can 
allways be user-derived from SimpleContext implementing multiple VTDNav 
functionality. Basically you're 99% right, with some caveats that should 
perhaps be documented, so let's do it your way :-)

Memory usage is not allways critical, sometimes performance can be 
gained from memory, sometimes that's a false argument. In this case an 
option should be given between fast position recall and small memory 
usage. In fact they are both very small comparing with DOM. My bet is 
that VTD can be better than DOM, even API-wise, and still faster than 
SAX, if we care to enhance the API.



Jimmy Zhang wrote:
> VTD-XML certainly still has a lot of growing up left...
> One old observation from early days of VTD-XML:
> Memory usage has strong performance implications as well...
> DOM's excessive memory usage directly contributes its slow 
> performance, VTD-XML's memory strategy is largely responsible for its 
> parsing performance...so VTD's mentality has always been to: reduce 
> memory usage whenever possible, that will, one way
> or another, lead to better performance...
> as setPosition(int i)'s performance, did your implemenation directly
> manipulate Location Cache tables? I will take a stab at it to see
> how fast it can get
> Concering the equal comparison of two node object, I think that
> the only condition to check is the the currentIndex value of tthe
> cursor location, assuming the same VTDNav instance...
> hashCode computation and equality can basically use that value...