views:

155

answers:

7

Hi,
My work uses a great number of a class instances.
For a memory optimization, I would like to know if the using of static method will be better than simple functions.
Thanks for any suggestion around the optimization of managing lots of objects.

+3  A: 

There is no difference between

public class Foo
{
     public Bar bar;
     public Bar baz;

     public bool Qux()
     {
         return this.bar != null;
     }
}

and

public class Foo
{
     public Bar bar;
     public Bar baz;

     public static bool Qux(Foo foo)
     {
         return foo.bar != null;
     }
}

in terms of memory consumption by a single instance. Methods consume memory per class, not per instance.

If course, you can save memory by not creating instances. So, if your static method makes instances unnecessary, go for static methods.

dtb
Not that I think it makes a difference in the present context but if the instance methods requires an entry in the vtable it would take up a bit more memory than methods that do not require a vtable entry.
Rune FS
@Rune: there is one v-table for a class, all objects of that class use the same one.
Hans Passant
@Hans The size of it depends on the number of methods in it which (might) require slightly more memory than had they been static. I did say I don.t think in makes a difference in this context :)
Rune FS
+2  A: 

As a general rule: the code of your methods is shared between instances - it's not like every instance gets it's own copy of the methods. You might want to have a look at how to manage instance data, though - the flyweight pattern comes to my mind here.

Jim Brissom
A: 

Does the class store any instance data or use any instance data for execution of the method? Then a static method won't work.

If the method doesn't utilize any of the instance data of the class, then making the method static would work.

If you can't make the method(s) static that you're interested in, you might consider implementing a pool for your objects.

When you need an instance, you get an available one from the pool, use it, and then return it to the pool when you're done with it. That way you don't have to create as many instances (but this assumes, of course, that you're creating many instances that don't get used often).

Justin Niessner
in the first case a static will still work if you pass in the instance
Rune FS
@Rune FS - Yes, it will. But, in that case, you're still going to have just as many instances created.
Justin Niessner
A: 

Making your methods static or not should not make much of a difference to the footprint of your class. If you end up instantiating your classes merely to call a member method, static might make a little difference.

If memory consumption because of many instances is a problem, you might want to have a look at the Flyweight pattern

LaustN
+1  A: 

Hurting your readability or changing your logic for performance issues is recommended only after you are completely sure whatever you plan to do would significantly help. This is not the case here because your solution will not really help from the first place, let alone "significantly". so the answer to your question is "no".

Oren A
A: 

Others' input is good. I would only add that if instances are being created and destroyed at a high rate, you will be losing a lot of time in memory management. You can rectify that by keeping pools of used objects, and re-use them without going to the memory allocator.

Mike Dunlavey
Really? I had thought this was only really an issue if there was a lot of objects dying in Gen 2
Conrad Frix
@Conrad: I've seen this in any language. I take stackshots, and a good percent of them can be in object construction, new, malloc, destruct, or gc (if there is one, delete if there is not). When that happens, pooling makes it go away, for a nice speedup.
Mike Dunlavey
A: 

Methods always attached to classes, not instances. The size of the instance in the memory does not depend on method count. Therefore, using static or instance variable is not related to the memory optimization at all.

tia