--- Aleksander Slominski <[EMAIL PROTECTED]> wrote: At first all entities in OM were nodes�using a burned in linked list. Later Attributes and Namespaces were stored using hash-maps and people were in doubt as to whether we need this burned in linked structure at all.
The use of collection classes like ArrayList or Vector instead of a linked structure will result in creating more objects at runtime and this would cost us performance (in terms of throughput of the engine) as the test shows. However, traversing and searching must also be looked into. The tests indicate that collection classes do not give us any advantage on sequential traversals either. In fact they seem add a significant overhead. As for the question of whether such traversals are done at all, please have a look at org.apache.axis.om.impl.llom.traverse.* In short, a linked structure seems better than using collection classes but not when entities are retrieved by QName. In this case the new tests that I have added gives *a hint* that the benefit gained by hashing out performs its overhead even for small numbers of attributes as 4~5. What�s the whole point of all this? We are not trying to optimize a legacy system at this point with time/cost/performance trade offs. Instead, we simply want to select the best possible organization for OM. --Dasarath > Dasarath Weeratunge wrote: > > >Hi Alek, > > > >have a look at > >https://svn.apache.org/repos/asf/webservices/axis/trunk/archive/java/scratch/dasarath/om/$1/summary.html > > > >Sorry for the messup with the tabs! > > > > > i think you need to modify how you do calculations - > having 0 ms timings > means you have either insanely fast or your > measurements are not right > and need to be done for more iterations to calculate > averages - repeat > calling testAL/LLElement so number of operations for > timing (defined as > node creation or node visiting) is more or less > constant *independent* > of number of children created / visited > > i am surprised to find out that there is method > traverse() in *Element() > class - no real application will use it so why to > test it? > > anyway it is micro micro benchmark and i am > generally *extremely* > skeptical about value of such tests ... what is this > test supposed to > determine? > > how results of this test reflects on SOAP processing > (especially with > incremental tree building from input stream)? > > i suspect that times spent traversing XML trees is > very very small (0 > ;-)) for any round trip measurements - it would be > nice to know what > parts currently takes most of time and then > profile/optimize that > instead of doing micro benchmarks on parts that may > have no impact on > overall performance ... > > alek > > > > >--Dasarath > > > >--- Aleksander Slominski <[EMAIL PROTECTED]> > wrote: > > > > > >>Dasarath Weeratunge wrote: > >> > >> > >> > >>>If you are in doubt about how much recent > >>>architectural changes may have affected (or > killed) > >>> > >>> > >>OM > >> > >> > >>>performance please look at the following test > >>> > >>> > >>results: > >> > >> > >>https://svn.apache.org/repos/asf/webservices/axis/trunk/archive/java/scratch/dasarath/om/$1/ > >> > >> > >>> > >>> > >>> > >>> > >>what is tab size you use? i am sure it is not 8 > >>chars ... > >> > >>i could not grasp what this table means and what > are > >>results - is it > >>slower, faster, how much? > >> > >>diff/currentTimeMillis > >> > >>impl N > >>M T S diff > >> > >> > >> > >------------------------------------------------------------------------------------- > > > > > >>LLElement(test1) 200 100 > >> 10000 1 > >> > >>ALElement(test2) > >> 1 11 > traverse/Object > >>get(int index) > >> > >> 5 11 > >> > >> 100 11 > >> > >> > >> > >> 1 35 > >> traverse/Iterator > iterator() > >> > >> 5 35 > >> > >> 100 35 > >> > >> > >> > >> > >> > >------------------------------------------------------------------------------------- > > > > > >>LLElement(test1) 200 10000 > >>100 6 > >> > >>ALElement(test2) > >> 1 21 > traverse/Object > >>get(int index) > >> > >> 5 26 > >> > >> 100 49 > >> > >> > >> > >> 1 45 > >> traverse/Iterator > iterator() > >> > >> 5 50 > >> > >> 100 72 > >> > >> > >> > >> > >> > >------------------------------------------------------------------------------------- > > > > > >> > >>alek > >> > >> > >> > >>>--Dasarath > >>> > >>>--- Eran Chinthaka <[EMAIL PROTECTED]> > wrote: > >>> > >>> > >>> > >>> > >>>>Hi all, > >>>> > >>>>This will some relate to the thread "Doubt on > >>>> > >>>> > >>Detail > >> > >> > >>>>Element in SOAPFault". > >>>> > >>>>AXIOM was not meant to check the compliance with > >>>>SOAP spec or anything else. > >>>>It will just hold the infoset. The reason behind > >>>> > >>>> > >>me > >> > >> > >>>>putting a SAAJ like api > >>>>on top of OM was to provide developer > convenience. > >>>>For example, rather than > >>>>saying element.getFirstElement(), developers > love > >>>> > >>>> > >>to > >> > >> > >>>>use > >>>>envelope.getHeader(). So, that was the intention > >>>> > >>>> > >>of > >> > >> > >>>>providing that sort of > >>>>SOAP jargon in to Axiom. This was our initial > >>>> > >>>> > >>idea. > >> > >> > >>>>But later, some have put some checks in to the > >>>> > >>>> > >>AXIOM > >> > >> > >>>>SOAP api. And the > >>>>earlier thread also was asking about this > >>>>validation. > >>>> > >>>>So I have a small question on this. What should > we > === message truncated === __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
