This week's book giveaway is in the OCAJP 8 forum. We're giving away four copies of OCA Java SE 8 Programmer I Study Guide and have Edward Finegan & Robert Liguori on-line! See this thread for details.
I realize this question's been around forever, but does ArrayList actually perform better than Vector? I heard somewhere that with either Java 5 or 6, the compiler is smart enough not to care that Vector is synchronized and Vector actually performs just as well as ArrayList. Is this true?
I've spent some time googling this and couldn't find an answer. Most of the results are just people's thoughts, and nothing I found specifically addressed the fact that performance may have changed since Java 1.2. Is there a good place to go to look up things like this?
As of JDK 6, the JVM may omit unnecessary synchronization if it can determine that only one thread can possibly access the instance being synchronized on. So if you have a Vector referenced only by a local variable, that is probably reachable only by the one thread that is running the method that defines the local variable, so the JVM may ignore synchronization on that Vector. I don't know that it's guaranteed that this will happen - most likely, it isn't. But there's a good chance.
More generally, the best way to find out which performs better in a prticular situation is to test it yourself. But this sort of thing varies depending on the platform and depending on exactly what your program is doing. And in the vast majority of cases it really doesn't matter. I think the best reason to avoid ever using Vector is just to stop the endless line of questions about the difference between the two classes.
[Non-responsive post removed. If you want to start a substantive discussion of the relative merits of C++ vs. Java, please start your own topic on the subject.] [ January 26, 2008: Message edited by: Bear Bibeault ]
Another performance difference -- one that's likely to matter more in cases where collection performance is really an issue -- is the algorithms these two classes use to allocate excess capacity.
If you've set the capacityIncrement property, they both behave more or less the same; if you have not, then Vector doubles the array size when it needs more space, while ArrayList multiplies it by 1.5. Doubling actually gives the theoretical best performance for starting from 0 and growing to a large size; multiplying by 3/2 actually tends to work out better in real-world situations where the list can both grow and shrink.
[EFH]: If you've set the capacityIncrement property, they both behave more or less the same;
It looks to me like if you set the capacityIncrement (available only in Vector) to any positive number, you get very different behavior, and generally very poor performance if your list length exceeds the capacityIncrement by a large factor. Which is probably why they abandoned this idea for ArrayList - it's close to useless for any practical application. If you set the capacityIncrement to zero or a negative number, it's as if you never set it at all. You get the standard behavior for Vector, which is what you want. [ January 27, 2008: Message edited by: Jim Yingst ]
Nikhil L Shah wrote:
Need to do performance tuning on my application.
What benchmark did you use to identify a Vector or ArrayList as the bottleneck? I would be willing to bet the difference in performance in ArrayList and Vector will be dwarfed by many other factors in a non-trivial application.
Have a look at our EnterprisePerformance FAQ for advice on how to identify and address the performance bottlenecks in an application (Note #13).
The second loop as an advantage as the optimizer might kick in by then and it may already have more of the classes it needs loaded by then. Unless you ran these tests multiple times it is inconclusive.
However, as the previous poster asked. Is this really your performance problem? Does your application do millions of gets and puts? If in the course of the day you do several million at best you would shave a fraction of a second off of your execution time for the whole day.