using static initialization blocks to improve performance

Question

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;

     }
}

Depends on use case, as usual ... If B is populated millions of times in a short time period it might matter, but doesn't have to. KISS, then optimize. — MicSim, Sep 05 '12 at 09:14

score 2 · Accepted Answer · answered Sep 05 '12 at 09:15

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.

I mean't declare all the fields in B that don't change as static final — Chetan Kinger, Sep 05 '12 at 09:31

score 0 · Answer 2 · answered Sep 05 '12 at 09:15

If you only keep a single instance of class B, which you modify and return from that method as appropriate, then you'll have to expect trouble: a caller cannot rely on the returned object containing the data he requested. In a single-threaded application, storing that value and accessing it later on will lead to trouble if there was a different call to the method in between. In a multi-threaded application, the content might even change without such a call from the current thread, as another thread might call the method and cause the object to change. The object might even be in an inconsistent state in between.

There might be cases where this can be used safely and reasonably, but from the general description you provide I'd advise against it. Perhaps a better solution would be factoring out the unchanging part of class B in such a way that B only holds the two changing values and a reference to another object holding the unmodifiable part. Of course this is only applicable if you control the implementation of B.

Amit Deshpande · Answer 3 · 2012-09-05T09:28:41.967

Given a class A containing method that populates N fields of another POJO class B using setters

So A has instance of B or List of instances of B?

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,

Why not to directly initialize N-2 Fields in B itself.

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?

If you use Static then B will be part of A class not object of A so B will be common for All A instances do you really want that?

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?

Please provide some code. In my opinion static blocks should be only used for configuration objects initialization.

using static initialization blocks to improve performance

3 Answers3