Return-Path: Delivered-To: apmail-ws-axis-dev-archive@www.apache.org Received: (qmail 76663 invoked from network); 23 Mar 2005 17:43:26 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (209.237.227.199) by minotaur.apache.org with SMTP; 23 Mar 2005 17:43:26 -0000 Received: (qmail 63781 invoked by uid 500); 23 Mar 2005 17:43:24 -0000 Delivered-To: apmail-ws-axis-dev-archive@ws.apache.org Received: (qmail 63713 invoked by uid 500); 23 Mar 2005 17:43:23 -0000 Mailing-List: contact axis-dev-help@ws.apache.org; run by ezmlm Precedence: bulk Reply-To: axis-dev@ws.apache.org list-help: list-unsubscribe: List-Post: Delivered-To: mailing list axis-dev@ws.apache.org Received: (qmail 63699 invoked by uid 99); 23 Mar 2005 17:43:23 -0000 X-ASF-Spam-Status: No, hits=2.5 required=10.0 tests=DNS_FROM_RFC_ABUSE,FORGED_YAHOO_RCVD X-Spam-Check-By: apache.org Received-SPF: pass (hermes.apache.org: local policy) Received: from web31701.mail.mud.yahoo.com (HELO web31701.mail.mud.yahoo.com) (68.142.201.181) by apache.org (qpsmtpd/0.28) with SMTP; Wed, 23 Mar 2005 09:43:21 -0800 Received: (qmail 76706 invoked by uid 60001); 23 Mar 2005 17:43:19 -0000 Comment: DomainKeys? See http://antispam.yahoo.com/domainkeys DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; b=dS37f2FbtkoCKIZXz4E5Tir1LPfj+aJtnGoX0w9K7rN4lZKl4/WJTsWpjn/bvn9nbSwdWuEbTJzrWQCZr9LicowflRMZ20DGC1ssHNBVzdFRH45+anLO78GCQqQowyyXay+X6w8LV5LVHfDB2U1dgjT/VmY4c3lqnyhrCo1L/us= ; Message-ID: <20050323174319.76704.qmail@web31701.mail.mud.yahoo.com> Received: from [203.94.95.33] by web31701.mail.mud.yahoo.com via HTTP; Wed, 23 Mar 2005 09:43:19 PST Date: Wed, 23 Mar 2005 09:43:19 -0800 (PST) From: Dasarath Weeratunge Subject: Re: [Axis2] What should we have in AXIOM ? To: axis-dev@ws.apache.org In-Reply-To: <42412AA3.3040308@cs.indiana.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Virus-Checked: Checked X-Spam-Rating: minotaur.apache.org 1.6.2 0/1000/N --- Aleksander Slominski 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 > 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 > 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