views:

515

answers:

9

I remembered someone telling me one good one. But i cannot remember it. I spent the last 20mins with google trying to learn more.

What are examples of bad/not great code that causes a performance hit due to garbage collection ?

A: 

One example would be object references that are kept in member variables oder static variables. Here is an example:

class Something {
  static HugeInstance instance = new HugeInstance();
}

The problem is the garbage collector has no way of knowing, when this instance is not needed anymore. So its usually better to keep things in local variables and have small functions.

Lemmy
Actually if your instance is 85000 bytes it will be allocated on the LOH(Large Object Heap) which is rarely scanned for roots and doesn't incur much overhead...
Matt Davison
ok but it still needs RAM that is therefore not available to other objects. my point is just that you should always define your variables at the smallest possible scope. beside being better style it just helps the GC better understand the lifecycles of your objects.
Lemmy
+1  A: 

When you have some loop involving the creation of new object's instances: if the number of cycles is very high you procuce a lot of trash causing the Garbage Collector to run more frequently and so decreasing performance.

Stefano Driussi
A: 
String foo = new String("a" + "b" + "c");

I understand Java is better about this now, but in the early days that would involve the creation and destruction of 3 or 4 string objects.

Paul Tomblin
+2  A: 

from an old sun tech tip -- sometimes it helps to explicitly nullify references in order to make them eligible for garbage collection earlier:

public class Stack {
  private static final int MAXLEN = 10;
  private Object stk[] = new Object[MAXLEN];
  private int stkp = -1;

  public void push(Object p) {stk[++stkp] = p;}

  public Object pop() {return stk[stkp--];}
}

rewriting the pop method in this way helps ensure that garbage collection gets done in a timely fashion:

public Object pop() {
  Object p = stk[stkp];
  stk[stkp--] = null;
  return p;
}
netzwerg
A: 

I can give you an example that will work with the .Net CLR GC:

If you override a finalize method from a class and do not call the super class Finalize method such as



protected override void Finalize(){
    Console.WriteLine("Im done");
    //base.Finalize(); => you should call him!!!!!
}

When you resurrect an object by accident


protected override void Finalize(){
    Application.ObjJolder = this;
}

class Application{
    static public object ObjHolder;
}

When you use an object that uses Finalize it takes two GC collections to get rid of the data, and in any of the above codes you won't delete it.

mandel
A: 
  • frequent memory allocations
  • lack of memory reusing (when dealing with large memory chunks)
  • keeping objects longer than needed (keeping references on obsolete objects)
aku
A: 

In most modern collectors, any use of finalization will slow the collector down. And not just for the objects that have finalizers.

Darron
A: 

Your custom service does not have a load limiter on it, so:

  • A lot requests come in for some reason at the same time (everyone logs on in the morning say)
  • The service takes longer to process each requests as it now has 100s of threads (1 per request)
  • Yet more part processed requests builds up due to the longer processing time.
  • Each part processed request has created lots of objects that live until the end of processing that request.
  • The garbage collector spends lots of time trying to free memory it, however it can’t due to the above.
  • Yet more part processed requests builds up due to the longer processing time…. (including time in GC)
Ian Ringrose
A: 

I have encountered a nice example while doing some parallel cell based simulation in Python. Cells are initialized and sent to worker processes after pickling for running. If you have too many cells at any one time the master node runs out of ram. The trick is to make a limited number of cells pack them and send them off to cluster nodes before making some more, remember to set the objects already sent off to "None". This allows you to perform large simulations using the total RAM of the cluster in addition to the computing power.

The application here was cell based fire simulation, only the cells actively burning were kept as objects at any one time.

whatnick