Dasarath Weeratunge wrote:
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 / visitedHi 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 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 recentOM
architectural changes may have affected (or killed)
performance please look at the following testresults:
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
Detail--Dasarath
--- Eran Chinthaka <[EMAIL PROTECTED]> wrote:
Hi all,
This will some relate to the thread "Doubt on
meElement 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
toputting a SAAJ like api
on top of OM was to provide developer convenience.
For example, rather than
saying element.getFirstElement(), developers love
ofuse
envelope.getHeader(). So, that was the intention
idea.providing that sort of
SOAP jargon in to Axiom. This was our initial
AXIOMBut later, some have put some checks in to the
infoSOAP api. And the earlier thread also was asking about this validation.
So I have a small question on this. What should we have in AXIOM ??
1. Shall we "KISS" Axiom, and let it be just a
theset holder. - If this is the case, this will not affect
Canperformance, due to
validation and stuff. And if we make it like this
how we gonna provide
validation or do we need to provide validation.
protection aroundwe leave this up to the__________________________________________________
user ?
2. Shall we make AXIOM SOAP stuff do validation on
SOAP 1.1 spec as well. - This will definitely affect the performance.
IMHO, I prefer option 1, which is basically my initial idea as well.
What do you all think about this ?
Thanks, Eran Chinthaka
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam
http://mail.yahoo.com
-- The best way to predict the future is to invent it - Alan Kay
__________________________________ Do you Yahoo!? Yahoo! Small Business - Try our new resources site!
http://smallbusiness.yahoo.com/resources/
-- The best way to predict the future is to invent it - Alan Kay
