I've done some benchmarks. The program with source code is attached to this posting. The goal of this benchmark is to measure the performance of different design alternatives for implementing readable and writable vector classes.
The Test
Tested were two classes (or interfaces) implementing a Vector3f version. The first class (or interface) provides a read-only access while the second read-write access. Additional, a static method "add" is introduced as implemented in the current Vector3f class.
Three different design alternatives were implemented:
Concrete: The first one (called "Concrete") implements a concrete readable class with final getters and protected fields. The writable class extends this class providing setters.
Abstract: The second version (called "Abstract") implements an abstract readable class with abstract getters and no fields. The writable class extends this class, defining the fields (public) and implementing final getters and setters.
Interface: The third version (called "Interface") defines a read-only interfaces with getters, the writable class implements this interface and defines all fields (public) and final getters and setters.
The static add method has a similar signature in all three versions: left and right vector are passed as read-only instances, the result is a writable instance. If the passed result is null, a temporary variable is constructed and returned, otherwise the result is filled.
The benchmark was executed 4 times, two times with a server VM and two times with a client VM. For each VM, 1000000 calls of the add method and a setter were repeated 100 and 1000 times. The result are shown below and illustrated in the image.
The Result
The last version using interfaces is the slowest one in all tests. Using an abstract class is more or less as fast as using a concrete readable class. Interestingly it is even sometimes a little bit slower (which I didn't expected)!
Also surprising (at least for me) is the fact that in some tests (with the server VM) creating new temporary instances (i.e. passing null as result parameter) is faster then using an in-out parameter.
The server VM is in all tests much faster then the client VM. in some cases about 5 times. Even the slowest server tests is nearly as fast as the fastest client test!
Conclusion
Using abstract readable base classes is the winner. It doesn't change the current access possibilities, i.e. accessing the fields of a vector directly or by using the getter. It is just as fast as using concrete classes. So, I think the optimal design would look like the one I submitted above in this thread, except that the readable classes become abstract and that the fields are defined as public attributes in the vector classes. On the other hand, using interfaces (which is the clear looser of this benchmark) may be the most flexible design. IMHO vector classes are like "native" types for 3D programming and an interface is seldom needed, so I personally prefer using abstract classes.
Remarks
I was really surprised by the results. I didn't expect the server VM to perform so much faster. What surprised me most is that in some cases using abstract classes (and getters) is even faster then using a concrete class.
elias did already suggested using abstract classes and he is right! Maybe I should have trusted him in the first place, but it was still interesting doing this benchmark. princec pointed out that we have to worry about design more then performance since new (and better) VM versions will be available in the near future. I think he is right, too. And even if I declared "abstract" classes as the winner, using interfaces may be a better design decision because it is more flexible. On the other hand, using abstract classes was 1.3 to 2 times faster then interfaces in the nearly all cases (except one weird exception), so I think we should use that design.
Since I added the classes (and the sources) you may try the benchmark on your machine. Since the performance of the VM is so important, I'm curious about your result.
Since I'm not an expert on benchmarks, nor on VMs, nor on 3D, I wouldn't be surprised if you find some design errors in the benchmark or in my argumentation :-)
The Numbers
$ java -server -jar benchmark.jar
Run benchmark, times: 100, count: 1000000
JRE 1.5.0_07 (Apple Computer, Inc.), Java HotSpot(TM) Server VM 1.5.0_07-87 ("Apple Computer, Inc.") on Mac OS X 10.4.10 (i386)
Concrete, create temp : 1,04 sec (1.040.273.000)
Concrete, pass result : 0,51 sec (511.121.000)
Abstract, create temp : 1,05 sec (1.052.720.000)
Abstract, pass result : 1,13 sec (1.126.970.000)
Interface, create temp: 1,04 sec (1.039.608.000)
Interface, pass result: 2,25 sec (2.248.686.000)
$ java -server -jar benchmark.jar 1000
Run benchmark, times: 1000, count: 1000000
JRE 1.5.0_07 (Apple Computer, Inc.), Java HotSpot(TM) Server VM 1.5.0_07-87 ("Apple Computer, Inc.") on Mac OS X 10.4.10 (i386)
Concrete, create temp : 10,84 sec (10.835.785.000)
Concrete, pass result : 5,04 sec (5.038.323.000)
Abstract, create temp : 10,51 sec (10.511.653.000)
Abstract, pass result : 9,64 sec (9.636.774.000)
Interface, create temp: 13,67 sec (13.669.681.000)
Interface, pass result: 22,45 sec (22.450.686.000)
$ java -client -jar benchmark.jar
Run benchmark, times: 100, count: 1000000
JRE 1.5.0_07 (Apple Computer, Inc.), Java HotSpot(TM) Client VM 1.5.0_07-87 ("Apple Computer, Inc.") on Mac OS X 10.4.10 (i386)
Concrete, create temp : 5,02 sec (5.024.559.000)
Concrete, pass result : 1,80 sec (1.797.204.000)
Abstract, create temp : 4,44 sec (4.444.387.000)
Abstract, pass result : 1,86 sec (1.864.297.000)
Interface, create temp: 6,87 sec (6.873.674.000)
Interface, pass result: 4,33 sec (4.327.192.000)
$ java -client -jar benchmark.jar 1000
Run benchmark, times: 1000, count: 1000000
JRE 1.5.0_07 (Apple Computer, Inc.), Java HotSpot(TM) Client VM 1.5.0_07-87 ("Apple Computer, Inc.") on Mac OS X 10.4.10 (i386)
Concrete, create temp : 51,42 sec (51.422.792.000)
Concrete, pass result : 18,05 sec (18.049.931.000)
Abstract, create temp : 50,21 sec (50.210.897.000)
Abstract, pass result : 18,46 sec (18.464.446.000)
Interface, create temp: 67,97 sec (67.965.217.000)
Interface, pass result: 43,23 sec (43.227.655.000)