Given an existing code base being used in production containing a class A that contains a method that populates N fields of another POJO class B using setters and returns the POJO to the caller and given that all instances of class B will be different in regards to only two field i.e, N - 2 fields will be the same across all instances of class B, would there be any performance gain if class A has a static reference to class B and initializes the fields of class B that don't change in a static init block? This way, the method in class A that was populating N fields of class B on each call will now have to populate only two fields which are different. This will also eliminate the need to create a new object of type B for each call to the method in class A. What are the implications of this approach in a multi-threaded application?
Alternately, we can declare all the fields in class B that don't change as static so that the method in class A only sets the fields that change per call. Either ways, will the performance gain be worth it or this change qualifies as premature optimization?
Example :
class A {
private static B b = new B();
static {
b.setSystem("MySystem");
b.setVersion("1.1");
}
public B getB(String name) {
b.setName(name);
return B;
}
}
given that all instances of class B will be different in regards to only two field
So I understand that you have more than one instance of B
This will also eliminate the need to create a new object of type B for each call to the method in class A.
But now you only have one instance of B - if A changes those 2 fields, all the places in your code that have a reference to that instance of B will see the change (assuming proper synchronization).
=> It is not clear whether you need one or more instances of B.
What are the implications of this approach in a multi-threaded application?
If you share the same instance of B accross threads, you need to make sure you use proper synchronization when writing and reading B's properties.
Alternately, we can declare all the fields in class B that don't change as static
Do you mean final?
Either ways, will the performance gain be worth it or this change qualifies as premature optimization?
It think it does qualify indeed. Especially since you don't seem 100% sure yet about what you need. So same advice as usual: go the easy and simple way. IF performance is not good enough, profile and determine what parts of the code need to be improved.
If you know you are going to be in a multi-threaded environment, you should probably avoid anything static and mutable - that will make your life easier and limit the risk of concurrency bugs.
Ideally, (1) try not to share objects accross threads - if you can't, then (2) try to share immutable objects - if you can't (3) make sure that you use proper synchronization and that you know what you are doing.