From: Jimmy Z. <cra...@co...> - 2007-03-02 21:20:23
|
Rodrigo, I went over your emails on this thread again and comes up a few questions... 1. In one of the emails, you attached a class capable of storing a single node position.. I am wondering why store just one? why not more? 2. In the code below, vn.setCtxFromNav and vn.setNavFromCtx seem to me equivalent to push() and pop myContext = new SimpleContext(null); //Or another size you like, but null works just fine while(ap.iterate()){ vn.setCtxFromNav(myContext); // do something messy vn.setNavFromCtx(myContext); } As to NodeRecorder, it is designed to be instantiated once and hold many nodes... not to be instantiated 10 times for 10 nodes... As to why NodeRecorder doesn't use the node format as in push pop and setCtx as in your patch... the main motivation is to conserve memory, push pop and setCtx all use full-expanded node representation which can be quite big for a complex document NodeRecorde's internal format is more compact, but the the representation is variable in length... The most compact node representation is to just use the index value which is always 32-bit per node... VTDNav can add a method that "recovers" the node position from a single index value of the node... All in all, the above three options are typical trade-offs between memory and computation * Pop push use the full expanded node representation which are constant in length and don't require and extra computation * Node recorder's internal node representation is compacted a bit, but is variable in length, and therefore can be accessed only sequentially * Using a single integer to represent a node is the most compact, but requires some CPU cyles to "recover" the node position... I would like ot know what you think of those options...and will take the discussion forward from that point on... ----- Original Message ----- From: "Rodrigo Cunha" <rn...@gm...> To: <vtd...@li...> Sent: Thursday, February 15, 2007 3:19 AM Subject: Re: [Vtd-xml-users] Random Access Proposal (take 2) > Well, just some ideas concerning what I think should be the nature of a > "context": > > - As light as possible to generate, manipulate and access (so just use a > simple context with minimun clutter). > - Comparable. > - Hashable efficiently (good and fast dispertion function). > - Possible to associate with VTDNav (so contains a pointer to VTDNav). > - Usable in another VTDNav (that's a tricky one, and unsafe, but makes > sense if you have various equal VTDNavs and a RMI-based system, so it > should be possible despite perhaps including dire warnings in the > documentation). > > Jimmy Zhang wrote: > > Yes, will try, but then again, there will always be a 2.1 :) > > > ------------------------------------------------------------------------- > Take Surveys. Earn Cash. Influence the Future of IT > Join SourceForge.net's Techsay panel and you'll get the chance to share > your > opinions on IT & business topics through brief surveys-and earn cash > http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV > _______________________________________________ > Vtd-xml-users mailing list > Vtd...@li... > https://lists.sourceforge.net/lists/listinfo/vtd-xml-users > |