I remember a discussion I recently had with a fellow developer about the memory footprint of private vs public properties. I stated that private ones have less of a footprint than public ones. He claimed it makes no difference. By the way, we were talking about C#.
Who is right and why?
Apparently there are differences in languages. I'm curious what they are as well.
In the context of what language?
In most languages, changing a method's accessibility from public to private or vice-versa will not at all affect its memory footprint. This is because the actual implementation and the actual invocation of the method does not change, only the way access to it is enforced (either at compile-time, or at run-time, based on the programming language in question.)
What will have an effect on memory footprint are other qualifiers, such as final in Java, virtual in C++, static, etc. These qualifiers may either directly influence memory footprint (the presence or absence of a corresponding entry in the class vtable), or indirectly influence memory footprint because of certain optimization assumptions that can be made by the compiler or by the runtime (e.g. non-virtual, static and/or final methods can be inlined, thus arguably increasing performance -- and most definitely increasing memory footprint.)
Of greater importance than memory footprint, when discussing how a method should be qualified, is what you can do to both (1) have the compiler (or the runtime, as depending on the language) validate some of your assumptions and intentions, and (2) convey those assumptions and intentions to the programmer who will review, reverse-engineer, alter, re-factor etc. the code after you:
private: do other classes, or descendants of this class, need direct access to this method? If not, make it private.protected: do descendants of this class (or this class itself), but no other classes (except maybe friend classes), need direct access to this method? If so, make it protected.static: does the method require access to member variables or to this? If not, it should be static (e.g. a utility method that depends solely on its arguments)const: does the method alter member variables or call non-const member methods on this or member variables? If not, it should be const (e.g. a getter)virtual: will the method need to be overridden? If not, it should not be virtualabstract (or pure virtual): does the method need to have an implementation in this class, if this class' descendants will override it? If not, make it abstract (or pure virtual)There are miscellaneous articles, lectures and posts out there regarding best practices for the above, transcending the boundaries of many a programming language:
It makes no difference. The property itself is just code and the metadata for it. Both are needed whether the property is private or public. Why would it make a difference?
The only way I can see private versus public making a difference is if you're obfuscating your code. By default, an obfuscator typically won't obfuscate the names of public members because then you won't be able to reflect on them. That will cost you a very small amount of memory, since the names of members are included in an assembly's metadata.
Note that I'm talking tiny amounts of savings here. Hardly worth mentioning really. But it's Friday afternoon.
HTH, Kent
There's no difference. And, even if there were, it would have to be pretty brutal to be worth changing your accessors to accommodate it.
Making a property or method private can enhance execution speed because the compiler may be more likely to inline the code, but I don't know of any instances where this reduces the memory footprint (Inlining may actually increase footprint at the benefit of speed).