1

Let's assume following code snippet:

public class NotThatWellWrittenClass {
   public static void doSmth() {
      /* 
        This code part is actually irrelevant.
      */
   }
}

Some other class would use that util as following: NotThatWellWrittenClass.do(), so the only overhead is actually related to performing a method call.

I really do not like programming that way, so I would like to refactor this part of code, while not breaking clients who are using static method call. Refactored snippet:

public class NotThatWellWrittenClass {
   public static void doSmth() {
      new WorkUtil().doSmth();
   }
}

public class WorkUtil() {
   public void doSmth() {
      /* 
          This code part is actually irrelevant.
      */
   }
}

Now, code is much more Object Oriented and easier to test and reuse. It now does, however, create an extra object (memory assignement) and perform instance method call instead of static call (which are optimized by JVM differently, I guess).

So, back to the question, does following refactoring provides any noticeable overhead? Maybe it should be performed in some other manner? (I could always cache an instance to my object, but is it worth it?)

I would like to get some in-depth explanation, thanks.

Community
  • 1
  • 1
ŁukaszBachman
  • 33,595
  • 11
  • 64
  • 74
  • 2
    I've never noticed any overhead caused by this. Mostly because there are far bigger algorithmic issues, sloppily coded bits and performance/OO trade-offs in almost every piece of code. But if you're really worried, declare your method and class as `final`, that gives the VM a hint that it doesn't need to do a virtual call. – biziclop Mar 05 '12 at 10:50

1 Answers1

0

Methods which are small e.g. 35 bytes long, can be inlined.

Only methods which are called often are optimised this way. e.g. 10,000 times or more.

If its rarely called, it should matter if it takes a few more nano-seconds anyway.

If WorkUtil.do() is simple enough the object allocation could be optimised away. The only alternative is to recycle the object yourself. It is fairly rare that you really need to do this. 

public class NotThatWellWrittenClass {
   private static final WorkUtil THE_WORK_UTIL = new WorkUtil();
   public static void do() {
      // could introduce thread safety issues as the object is now shared.
      THE_WORK_UTIL.do();
   }
}
Peter Lawrey
  • 525,659
  • 79
  • 751
  • 1,130
  • Those static methods can be rather big, I cannot make any assumptions on their complexity. Moreover - since it's static method, I cannot make sure that it won't be called in a bad manner, for instance 1k times per second. I'm just seeking general approach, whether or not this refactoring is a good practice or not. – ŁukaszBachman Mar 05 '12 at 10:53
  • @ŁukaszBachman Are you coding a library or an end product? If it's an end product, you have full control over how many times it's called. Plus if the method itself is doing more than a handful of simple operations, any overhead will have less of an impact. – biziclop Mar 05 '12 at 11:03
  • End product, I know that I could analyze sources to see how it's being used right now, but since I'm new to the dev team - I cannot have assurance that someone hasn't been using this util method in some other subproject. – ŁukaszBachman Mar 05 '12 at 11:52