axis-java-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dasarath Weeratunge <dasarathweeratu...@yahoo.com>
Subject Re: [Axis2] What should we have in AXIOM ?
Date Wed, 23 Mar 2005 17:43:19 GMT
--- Aleksander Slominski <aslom@cs.indiana.edu> 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 <aslom@cs.indiana.edu>
> 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 <chinthaka@opensource.lk>
> 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 

Mime
View raw message