axis-java-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Aleksander Slominski <as...@cs.indiana.edu>
Subject Re: [Axis2] What should we have in AXIOM ?
Date Wed, 23 Mar 2005 21:32:06 GMT
Dasarath Weeratunge wrote:

>--- 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 
>
where did this conclusion come from? data? my experience and cursory 
analysis of java.util shows that LinkedList requires 2 extra objects for 
each entry

>and this would cost us
>performance (in terms of throughput of the engine) as
>the test shows. 
>
i have serious doubts about that - ArrayList (and Vector) takes less 
memory as they do not need to keep a wrapper (LinkedList.Entry) that has 
next/previous link whereas ArrayList has just allocated memory for 
actual objects + some empty slots (typically less than half of size) + 
size (int).

for small size not only array access is faster but it may take less 
memory. in particular only difference is that linked list allows fast 
inserts - how important is that? typical element have only few children 
(0-8 or less) so insertion is very cheap even for arrays

and anyway that could be tunable as both LinkedList and ArrayList 
*implements* List

so use List and allow switching if it becomes a problem ...

>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. 
>
well it is not clear to me and i see no proof to convince me at all...

>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.
>  
>
this is obvious - however keep in mind that majority of elements have 
lest than 2 attributes and any hashtable is very memory heavy as it 
allocates slots table (see for example HashMap impl in java.util ...)

i think keeping memory footprint usage low is way more important then 
0...01% improvements in performance ...

>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.
>  
>
easy to use and *flexible* API is much more important (as long it is 
possible to implement it with reasonable performance and low memory 
footprint ...)

alek

>--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 
>  
>


-- 
The best way to predict the future is to invent it - Alan Kay


Mime
View raw message