Method Placement and Optimization
Assume that we're going to create alot of instances of a class. Further assume that they're all going to store a value that isencoded somehow. Therefore in addition to accessor methods, methods need to be created to encode & decode the data.
My question is, in terms of performance & memory footprint does it make any difference where those methods are added? i.e. instance methods, static methods or static utility methods in another class
Just to simplify things I'm going to say that the en/decode method doesnot spawn a thread.
I suppose I'm just trying to wrap my head around how object instances are treated in memory & if their footprint grows in size by adding operations to them. I'm particularly concerned with scalability with regards to making many many instances of a single object.
[861 byte] By [
gregor42a] at [2007-10-2 19:57:35]
> My question is, in terms of performance & memory
> footprint does it make any difference where those
> methods are added? i.e. instance methods, static
> methods or static utility methods in another class
It's not likely to make a noticeable difference. Static methods might be a bit faster to access, since they're not polymorphic, but method access time compared to the time to execute an "encode" or "decode" method is almost certainly negligible.
> I suppose I'm just trying to wrap my head around how
> object instances are treated in memory & if their
> footprint grows in size by adding operations to them.
No.
The class will get bigger, but there's only one copy of each method body for each class. Instances of the class do not get their own copies of method code.
> I'm particularly concerned with scalability with
> regards to making many many instances of a single
> object.
The size of the object's data, not its methods, is what will limit this.
jverda at 2007-7-13 22:36:59 >
> > My question is, in terms of performance & memory
> > footprint does it make any difference where those
> > methods are added? i.e. instance methods, static
> > methods or static utility methods in another class
>
> It's not likely to make a noticeable difference.
> Static methods might be a bit faster to access, since
> they're not polymorphic, but method access time
> compared to the time to execute an "encode" or
> "decode" method is almost certainly negligible.
>
>
> > I suppose I'm just trying to wrap my head around
> how
> > object instances are treated in memory & if their
> > footprint grows in size by adding operations to
> them.
>
> No.
>
> The class will get bigger, but there's only one copy
> of each method body for each class. Instances of the
> class do not get their own copies of method code.
>
I am not sure if this is true. If a method is not static the instance classes will get their own copies of method code.
> > The class will get bigger, but there's only one
> copy
> > of each method body for each class. Instances of
> the
> > class do not get their own copies of method code.
> >
> I am not sure if this is true. If a method is not
> static the instance classes will get their own copies
> of method code.
No, absolutely not. Each instance gets its own copy of instance data, but not of code. There would be no reason to do that.
jverda at 2007-7-13 22:36:59 >
> > I am not sure if this is true. If a method is not
> > static the instance classes will get their own
> > copies
> > of method code.
>
> No, absolutely not. Each instance gets its own copy
> of instance data, but not of code. There would
> be no reason to do that.
This is absolutely correct, there is only copy of the code per Class definition not instance.
OP should also checkout the Flyweight pattern particularly if the data is fine grained.
If this is the case, then how does java differentiate between a static method and a non-static method.I am not trying to argue here, just trying to understand.
> If this is the case, then how does java differentiate
> between a static method and a non-static method.
A non-static method is executed on a class instance allright; that doesn't mean that every object's memory representation should have the method's code duplicated. A non-static method operates on an instance identified inside the method by 'this'. Called on different objects, the method will 'see' different values of this, and thus see different values for the object's fields.
Lokoa at 2007-7-13 22:36:59 >
> If this is the case, then how does java differentiate> between a static method and a non-static method.By some bit in the method header, I suppose.
jverda at 2007-7-13 22:36:59 >
remember that all a method is is an area of memory that the JVM executes. the JVM knows the difference between a static and an instance method because of the modifiers in the methods declaration. the concept of a method being attached to a class or an object is an abstraction, the reality is that the JVM is given a pointer to an area of memory that has the method, and executes it. if it's a static method, the JVM will be given a pointer to the static members of that class, and if it's an instance method, a pointer to the object in question's members. it's all just memory as far as the thread of execution is concerned, 'static' and 'instance' are language-level ( I mean bytecode here rather than source, but still an abstraction ) concepts
some languages ( I don't know which ) do indeed attach a copy of method code to each instance of a class, but Java, having the intent that code written on your desktop PC will run in a JVM on a phone, makes more efficient use of the heap
> > If this is the case, then how does java
> differentiate
> > between a static method and a non-static method.
>
> A non-static method is executed on a class instance
> allright; that doesn't mean that every object's
> memory representation should have the method's code
> duplicated. A non-static method operates on an
> instance identified inside the method by 'this'.
> Called on different objects, the method will 'see'
> different values of this, and thus see
> different values for the object's fields.
Another way of saying the same thing would be that an instance method is simply a static method with an extra arg: this. In python this is explicit (which I don't like) in the method declaration. In java the "this" arg is cleverly hidden in front of the method call.
~Cheers
