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

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

I keep them in a HashMap, for example, or in a TreeMap, etc... rarely on 
a simple list.

The key is generally a string I would need to get in more or less 
convoluted ways from the node during a sequencial search. The node 
itself contains a lot more info I only want to retrieve in the future if 
it's needed, or else I would cache the info itself  :-D

If instead of keeping a context I can keep a simple integer and then 
order a VTDNav "hey you, get this integer you told me to keep and go to 
node you bookmarked" I would say it's ok, if the operation "get to the 
node" is fast.

So, you're suggesting an API that would work like this:

RandomNodeRecorder xpto = new RandomNodeRecorder(navigator);
// xpto is the bookmark keeper organized in a way Jimmy likes :-)
int mark = xpto.keepPos();
/* do some stuff here */
boolean xpto.fetchPos(mark); // back to the bookmarked node
xpto.del(mark); // don't need the mark any longer

I still fail to understand why shoudn't a context be kept outside the 
structures you seem to like :-)

Memory is cheap, and for example, if I keep a hash of NEs, and each NE 
occupies a few KB itself, it's irrelevant if I'm gona use a few more 
bytes for each NE.

I'm not suggesting one should keep large structures containing any 
single node in the document, ok? But the random access to a cached node 
must be fast. I emphasize: fast random access to cached nodes.

As far as I understand the SimpleContext structure grows 4 bytes for 
each depth level, so a deeper node consumes more space, right? So a 
really deep node, let's say, at level 10, will consume 40 extra bytes, 
plus the base consumption... that's 48 bytes, quite small, unless the 
node is small and irrelevant.

--
Rodrigo

Jimmy Zhang wrote:
> Rodrigo, in one of the early emails you mentioned that
> your app sometimes keeps thousands of those nodes (or context),
> how do you tell them apart? There got to be some data
> structures to store those context info, right?
> What if it is implemented such that
> 1. those contexts/nodes are stored in a linear buffer, which
> is more space efficient than allocating individual objects
> 2. You can address those nodes by using an integer, sort
> like a VTD record...
> would you consider the design outlined above can be useful
> to your app?
>
> Jimmy