Do static members help memory efficiency?

Question

If I have a class that I expect to be used in thousands of instances in a memory-sensitive application, does it help if I factor out static functionality to static members?

I imagine that static methods and variables are stored once per class while for non-static members there has to be something stored for each instance.

With member variables, it seems quite clear, but what kind of data is stored for methods?

I'm working in Java, but I imagine some general rules to apply in other managed environments (such as .NET), too.

Answer 1

The only difference between static methods and non-static (instance) methods behind the scenes is that an extra, hidden parameter (this) is passed to instance methods and that instance methods might be called using an indirect dispatch (if virtual). There is no additional code space taken.

Edit:

---

My answer focused on methods, but on closer reading I see that the question is more about static data. Yes, static data will in a sense save memory since there's only a single copy of it. Of course, whether or not data should be static is more a function of the meaning or use of the data, not memory savings.

If you need to have a large number of objects and want to conserve memory, you may want to also investigate if using the 'Flyweight' pattern is applicable.

Answer 2

The simple answer is yes. Creating an instance everytime there are none equals recreating the entire object, static methods and variables generally consumes less memory depending on how they are used. Of course if you only need to create one instance throughout your entire program, there's no difference. And remember you can always pass instances along as references where you can't have static objects and you need to reuse them.

Answer 3

The decision shouldn't be made on the grounds of efficiency - it should be made on the grounds of correctness.

If your variable represents a distinct value for each instance, it should be an instance variable.

If your variable is a common value associated with the type rather than an individual instance of the type, it should be a static variable.

You're correct, however - if you have a static variable, you won't "pay" for that with every instance. That just adds an extra reason to make variables static where they don't represent part of the state of the object.

When you mention methods in your question, are you talking about local variables? You'll get a new set of local variables for every method call - including recursive calls. However, this doesn't create a new set of static or instance variables.

Answer 4

If you make a member variable static, you save memory per-instance (assuming there's more than one instance), but the real gain is that you don't have to work at keeping all those non-static members consistent with each other, and you don't need a current instance in order to access the static member.

If you make a method static, you save a few bytes on the stack for each nested call (there's no implicit 'this' parameter), but that's only relevant if you're doing very heavy recursion. Of course if the function needs to know which instance you're dealing with, you'll need an explicit parameter to replace the implicit 'this' anyway, so you gain nothing.

There is no per-instance cost to having a static method, or for that matter, a non-static method. The costs occur on calls.

The real reason to use a static method is because there is no instance - at least when you call the method. For example, you might use a static method to create and initialise instances (one of the "factory" design patterns), or to reference a singleton instance.