Heinz Drews wrote:
hi,I disagree with you on the term "not significant" An increase by 27s I would see as serious.
that it is just 8% speedup in time to sort array list over vector with N^2 algorithm (speedup is defined as time for slow code divided by time for faster code - in this case it is 355/328)
please note that speedup would only be achieved in AXIS if the *most* of what AXIS is doing is to manipulate Vectors. instead i would estimate that time that AXIS is spending on vector manipulations is quite small- let say 1% so then expected speedup for AXIS would be around 0.08% ....
i think that possible speedups in AXIS when hot spots are identified and fixed should be anywhere in between 50-1000% (speedup defined as above) and i would say that this is a salary increase i would like to see and not just 0.08% :-)And the percentage as a salary increase would also not be seen as insignificant.
those estimations are based on my experience with xml and soap processing and in AXIS case XML processing, network latency optimizations (like HTTP chunking) and memory overhead minimizing may have much bigger impact on overall performance (see for example our paper on SOAP processing http://www.extreme.indiana.edu/xgws/papers/sc00_paper/ and some results on optimal XML processing i collected long time ago: http://www.extreme.indiana.edu/~aslom/exxp/)
not sure what you mean by it - i do not think AXIS is sharing Vectors between multiple threads so there is virtually no synchronization required otherwise different type of tests that uses wrapper Collection.|synchronizedList() would be required |- i have run test on windows 2000 with other applications running in background so it was not single threaded environment either.And I assume that your measurement was done in a single-threaded environment. The performance enhancements for synchronization in >1.4 are only advertized for "uncontended" environments.
new JVMs (such as hotspot in JDK 1.4) seems to be able to handle very efficient monitors and overhead of synchronization is much less than it used to be as those results indicate.Everything which does not add benefit is overhead and has to be avoided. If an instance of List is used local in a method why using then a synchronized implementation? There can't be a concurrency.
i do not argue about that (i actually agree) just that Hotspot (or any other modern JVM JIT) alleviates many of those problems.If the List is concurrently accessed then the method level synchronization provided by Vector is not useful in most of the cases. In case of a scenario to iterate through the list to find a element to process the complete iteration loop has to be synchronized to avoid that two threads will find the same element. That the get methods are synchronized does not help. A lot of other scenarios show also that the fine grain method synchronization done by Vector does not add real thread safeness.
they still live in J2ME and MIDP profile and are doing very well there .I see Vector and Hashtable as wrong gone experiments and put them into the cabinets next to T.Rex and others.
i am not really arguing against moving everything to use List i am just a bit uncertain that motivation as stated (performance improvement) may be better served when optimizing other parts of AXIS ....
BTW: this discussion of ArrayList vs Vector is nothing new (http://www.javaworld.com/javaworld/javaqa/2001-06/03-qa-0622-vector.html) moreover i have added more results (provided by Dave that ran those tests on Athlon 2.0+ with Windows XP and JDK 1.4.1) that seems to indicate that using Vector may be faster than ArrayList (?!) with Client HotSpot on some machines - one more argument for not depending too much on benchmarks ...
thanks,
alek
--
"Mr. Pauli, we in the audience are all agreed that your theory is crazy. What divides us is whether it is crazy enough to be true." Niels H. D. Bohr
