Alek, I don't want to argue that the use of ArrayList instead of Vector is the cure for performance problems.
My argument is that using an obsolete implementation of List which has a performance penalty compared to the preferred implementation is unwise even when the penalty is marginal. The improvement comes for free, one of the nicest gains. > >I disagree with you on the term "not significant" > >An increase by 27s I would see as serious. > > > hi, > > 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% .... > > >And the percentage as a salary increase would also not be > >seen as insignificant. > > > 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% :-) The numbers you provided show 8%. Your trick is nice, in the argumentation with my boss I calculate the increase I want as a percentage of the total salary volume of the company. This tiny bit he has to happily agree with :-) > 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/) I will read them with great interest, I always hunt for improvements. > >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. > > > 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. I wanted to express that the performance enhancements in 1.4.1 handling synchronization are only achieved if there is no concurrency. The measurement looks different in a contended scenario. > >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. > > > 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. Because the effectively optimize away the unnecessary use of synchronization. But still with a little price tag. And the use of 1.4.1 is not guaranteed cross all platforms. > >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. > > > i do not argue about that (i actually agree) just that Hotspot (or any > other modern JVM JIT) alleviates many of those problems. Not the point I tried to express. I get the impression that using Vector is seen as a guarantee for thread-safeness which is not the case. > >I see Vector and Hashtable as wrong gone experiments > >and put them into the cabinets next to T.Rex and others. > > > they still live in J2ME and MIDP profile and are doing very well there . There are also still in 1.4.1. But my impression is that Joshua Bloch, the Lord of the Collections, sees them as obsolete. And I would follow his leadership, I think that the Collections are a nice piece of architecture and implementation. Naturally with the exception of the heritage: Vector, Hashtable, Stack, Properties > 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 ... I don't want to raise the impression that I try to start any kind of religious war. Especially not around benchmarks. The switch from Vector the ArrayList gives a little bit of relief, on some platforms more on other less, without a real effort. Best regards, Heinz
