From: Jimmy Z. <cra...@co...> - 2007-03-06 03:57:09
|
I see... in last email you asked why VTD-XML 1.0 contains the bookmark class that you described ... actually this question was very much part of the discussion early on around 1.0 release... The reason is that, if you care to dig into VTD-XML's XPath release.. you will find that the bookmark class is not necessary to implement the entire XPath 1.0 spec... that kinda shifted our decision towards not offering this feature... besides the design of the core VTD-XML API (especially methods within VTDNav) needs to be well-thought out as it is something that affects every VTD-XML user...Let me think about this a bit more on how to address this issue that you raised.. one way may be to implement this feature in an added-on module... ----- Original Message ----- From: "Rodrigo Cunha" <rn...@gm...> To: "Jimmy Zhang" <cra...@co...> Cc: <vtd...@li...> Sent: Monday, March 05, 2007 3:39 PM Subject: Re: [Vtd-xml-users] Random Access Proposal (take 2) >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 > |