Dasarath Weeratunge wrote:
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--- 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 usi 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).
performance (in terms of throughput of the engine) as
the test shows.
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...
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 ...)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.
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 tryingeasy to use and *flexible* API is much more important (as long it is possible to implement it with reasonable performance and low memory footprint ...)
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.
alek
--Dasarath
Dasarath Weeratunge wrote:
https://svn.apache.org/repos/asf/webservices/axis/trunk/archive/java/scratch/dasarath/om/$1/summary.htmlHi Alek,
have a look at
i think you need to modify how you do calculations -Sorry for the messup with the tabs!
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
wrote:--Dasarath
--- Aleksander Slominski <[EMAIL PROTECTED]>
killed)
Dasarath Weeratunge wrote:
If you are in doubt about how much recent
architectural changes may have affected (or
arehttps://svn.apache.org/repos/asf/webservices/axis/trunk/archive/java/scratch/dasarath/om/$1/OM
performance please look at the following testresults:
what is tab size you use? i am sure it is not 8 chars ...
i could not grasp what this table means and what
-------------------------------------------------------------------------------------results - is it slower, faster, how much?
diff/currentTimeMillis
impl N M T S diff
traverse/Object
LLElement(test1) 200 100 10000 1
ALElement(test2) 1 11
iterator()get(int index)
5 11
100 11
1 35 traverse/Iterator
-------------------------------------------------------------------------------------5 35 100 35
traverse/Object
LLElement(test1) 200 10000 100 6
ALElement(test2) 1 21
iterator()get(int index)
5 26
100 49
1 45 traverse/Iterator
-------------------------------------------------------------------------------------5 50 100 72
wrote:
alek
--Dasarath
--- Eran Chinthaka <[EMAIL PROTECTED]>
convenience.Detail
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
putting a SAAJ like api
on top of OM was to provide developer
loveFor example, rather than
saying element.getFirstElement(), developers
to
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
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
