1

Is it correct to assume that calling a static method is fast compared to the allocating and garbage collecting an integer?

Or, in other words would either fh1 or fh2 be preferable? In fh1 allocation is avoided but fh2 seems simpler. In this case the G.f() is a relatively simple method which will be called often. fh2 and fh1 will also be called often (potentially as many as 30 times per second).

Pseudo Code:

class G {
  static method int f() {.......}
}

class H {
  method fh1(){
    somemethod1(G.f());
    somemethod2(G.f());
    somemethod3(G.f());
  }

  method fh2(){
    int a = G.f();
    somemethod1(a);
    somemethod2(b);
    .....
  }
}
DonGru
  • 13,532
  • 8
  • 45
  • 55
tjb
  • 11,480
  • 9
  • 70
  • 91
  • you say allocation is avoided in fh1, but what happens in G.f() then? – peko Sep 21 '11 at 13:47
  • @peko, for example G.f() could compute a derived value using several static member variables of class G by applying a mathematical formula to them (other things are also possible) – tjb Sep 21 '11 at 14:22

4 Answers4

1

The reason I would use a static method in this particular situation is if the int value had the potential to change. In other words, if G.f() is performing some logic and the 1st invocation might be different from the 10th invocation, sure, use a static method. Static methods such as this provide a way to reduce code by reusing logic and keeping logic in a manageable state so if your logic needs to be changed, you only have to change it in one place.

That being said, in method fh1, what would be the potential for varying results if G.f() would change in the span of time it takes to call G.f() three separate times in fh1()? Probably very small, but still worth considering.

I would probably opt for fh2() for consistency. The performance difference is likely negligible.

Russell Shingleton
  • 3,176
  • 1
  • 21
  • 29
1

30 times per second is not often (1 million times per second is often). Hence there is no problem here, so don't optimize it.

Having said that, fh2 will be more efficient, allocation is cheaper than function calls.

Thirler
  • 20,239
  • 14
  • 63
  • 92
1

You are not "allocating" nor "garbage collecting" an integer in your example.

Rather, in fh2, a lives on the stack and it does not need additional time to allocate/deallocate it.

How long a method call takes to completion depends entirelsy on the method's code. The call alone is fast, yet still slower than nothing. Therefore, I'd use the fh2 version.

Ingo
  • 36,037
  • 5
  • 53
  • 100
  • I don't understand, when you make a variable like int a, and then the function call ends, doesn't "a" get garbage collected after a while? Are you saying that it is reused? – tjb Sep 21 '11 at 15:42
  • No, it is just a slot in the stack, and the stack pointer basically gets decremented 8or incremented) some amount, leaving the int, which is a roimtive as it is. The stack is not garbage collected. – Ingo Sep 21 '11 at 17:30
  • Thanks, those looking for additional info on this subtopic should look at http://stackoverflow.com/q/2474622/530634 – tjb Sep 21 '11 at 18:52
0

We should forget about small efficiencies, say about 97% of the time: premature optimization is the root of all evil. Yet we should not pass up our opportunities in that critical 3%. A good programmer will not be lulled into complacency by such reasoning, he will be wise to look carefully at the critical code; but only after that code has been identified

© Donald Knuth

kzotin
  • 5,365
  • 3
  • 29
  • 36