variables declaration....

[senthil nathan]

Hi,
Is declaring variables inside a method is efficent or declaring it outside is efficient.
Whta are the Advs and Disadvs of both.
Thanks.
Senthil

[Marilyn de Queiroz]

You should declare it inside unless you have a good reason to declare it outside the method.

[Max Habibi]

It really depends on your memory usage. If you're going to be calling the method hundreds of times, then you might be better of declaring the variable outside and using it inside. That way, you won't have to create it hundreds of times. However, if you're going to be using the method less often, then all things being equal, you're better of declaring it inside.
HTH,
M

[Ilja Preuss]

Max, declaring a local variable doesn't cost any time afaik. I guess accessing a field might be even more expensive than accessing a local variable, but most probably you won't notice the difference anyway...

[Max Habibi]

Ilja,
If a method declares a variable internally, and then it(the method) is called several hundred times, then the the variable will be instantiated hundreds of times. OTOH, if the variable declared outside of the method, and used by the method, then it is only created once. It's just a denormalization. But, all things being equal, I agree that you probably declare your methods internally. But all things aren't always equal ;-).
HTH,
M

[Anonymous]

The point is, this only happens if thread access the method at the same time. Normally you should look where you need your variable.
I think declaration is no question of performance in our times. If you start declaring a large amount of objects than it could be, but then you should check your app design.
So normally the question where to define your variables is answered by the design of your class.
You have to differ between member variables which describe your class and simple variables which i would call helper which are needed just for execution of a method

[Ilja Preuss]

Originally posted by Max Habibi:
If a method declares a variable internally, and then it(the method) is called several hundred times, then the the variable will be instantiated hundreds of times. OTOH, if the variable declared outside of the method, and used by the method, then it is only created once.

A variable doesn't get instantiated, only objects.
In most JVMs, local variables will be placed on the stack. As the amount of memory needed for all the local variables of a method can be evaluated at "compile time" and a method call needs stack memory anyway, a local variable wouldn't need any additional commands to get its memory allocated.
So I guess in most JVMs the number of local variables in a method wouldn't have a negative impact on performance. Of course that is only a guess, but I think it is the way to bet.
[ July 03, 2002: Message edited by: Ilja Preuss ]

[Max Habibi]

A variable doesn't get instantiated, only objects.

A variable is the name given to an instantiated object. For example, in String myName = new String();, myName is variable. You're probably thinking of the distinction between primitives and Objects. But that's neither here or there.

In most JVMs, local variables will be placed on the stack. As the amount of memory needed for all the local variables of a method can be evaluated at "compile time" and a method call needs stack memory anyway, a local variable wouldn't need any additional commands to get its memory allocated.

I think I'm failing to be clear. Consider

....
MyHugeObject mho = new MyHugeObject();
...
for (int i=0; i<300; i++){
  useMyHugeObjectEffeciently();
}
method void useMyHugeObjectEffeciently(){
  mho.doStuff();
}

vs...

...
for (int i=0; i<300; i++){
  useMyHugeObjectEffeciently();
}
method void useMyHugeObjectInEffeciently(){
  MyHugeObject mho = new MyHugeObject();
  mho.doStuff();
}

The second way is more memory intenstive, regardless when 'when' the memory gets allocated, because of the class's design.
HTH,
M
[ July 03, 2002: Message edited by: Max Habibi ]

[Ilja Preuss]

Originally posted by Max Habibi:
A variable is the name given to an instantiated object. For example, in String myName = new String();, myName is variable.

A variable is either a primitive value or a *reference to* an object. In your example, myName is the name of a reference to a String. This reference resides on the stack. The String itself resides on the heap, once instanciated.
Notice that a reference variable doesn't have to reference an object (if you set it to 'null') and that an object doesn't need to be referenced by a variable (it is totally legal to write something like 'System.out.println(new String().length());').

You're probably thinking of the distinction between primitives and Objects.

No, I am thinking of the distinction between references and objects.

The second way is more memory intenstive, regardless when 'when' the memory gets allocated, because of the class's design.

But that is because of the instantiation of the MyHugeObject (via the 'new' keyword), not because of the declaration of the mho variable.

[Marilyn de Queiroz]

A variable is a reference to something. That something may be either a primitive or an object.

[arun mahajan]

Originally quoted by Max Habibi
The second way is more memory intenstive, regardless when 'when' the memory gets allocated, because of the class's design.

Originally quoted by Ilja Preuss
But that is because of the instantiation of the MyHugeObject (via the 'new' keyword), not because of the declaration of the mho variable.

Thanks Ilja for all your posting. It is really interesting. But my question is :
even if it is because of 'new' keyword, do you mean that Max second method will be more memory intesive.
regards,
Arun
[ July 04, 2002: Message edited by: arun mahajan ]

[Ilja Preuss]

Originally posted by arun mahajan:
even if it is because of 'new' keyword, do you mean that Max second method will be more memory intesive.

The answer is: "Most probably..."
The first example is instanciating one object, whereas the second instantiates 200 of them. Of course only one of them is referenced at the same time, so the others *might* get garbage collected - or they might not, depending on the implementation and configuration of the garbage collector.

[Max Habibi]

Ijla,
Regarding variables: I think we're saying the same thing, only in symatically different ways.

The answer is: "Most probably..."
The first example is instanciating one object, whereas the second instantiates 200 of them. Of course only one of them is referenced at the same time, so the others *might* get garbage collected - or they might not, depending on the implementation and configuration of the garbage collector

:-). I that that's a very, very, very slight *might*: any garbage collector that cleaned out MyHugeObject before iterating through the loop again should probably be reexamined. The answer is yes, the second way is much less memory intensive, by design.
[ July 08, 2002: Message edited by: Max Habibi ]

[Ilja Preuss]

Originally posted by Max Habibi:
Regarding variables: I think we're saying the same thing, only in symatically different ways.

Well, we possibly *mean* the same thing, but it seems to me that we are *saying* substantially different things.

Consider your examples slightly modified:

....
private MyHugeObject mho;
...
for (int i=0; i<300; i++){
  useMyHugeObjectIneffeciently();
}
method void useMyHugeObjectIneffeciently(){
  mho = new MyHugeObject();
  mho.doStuff();
}

Here, the variable mho is declared only once (as a member variable), but MyHugeObject is instanciated as often as in your second example. The performance of this solution will probably more resemble that of your second solution than that of the first.
Does that help?

[Max Habibi]

Well, we possibly *mean* the same thing, but it seems to me that we are *saying* substantially different things

I say a variables is "the name given to " a variable, you say it's "a reference to" a variable. AFAIK, that's a slight variation in termanology.

....does that help?

It helps explain where you're coming from. You're addressing the literal question "Is declaring variables inside a method is efficent or declaring it outside is efficient." by focusing on the word "declare". I'm addressing it based on what I consider to be the interesting part: that is: "What are the Advs and Disadvs of both.". That's why my reply goes into the pros and cons, explores the ramifications of each, and gives examples of when one path or another might be appropriate. Just different styles of helping people, nothing to get worked up about. Hopefully, the original poster picked up something useful.
HTH,
M
[ July 08, 2002: Message edited by: Max Habibi ]

[Ilja Preuss]

The other way around:

....
MyHugeObject mho = new MyHugeObject();
....
for (int i=0; i<300; i++){
  useMyHugeObject(mho);
}
method void useMyHugeObject(MyHugeObject mho){
  mho.doStuff();
}

Here, we are using a local variable (a parameter) in the useMyHugeObject method, but it only gets instanciated once. As declaration happens at compile time, that most probably doesn't present any performance issue.
[ July 08, 2002: Message edited by: Ilja Preuss ]

[Ilja Preuss]

Originally posted by Max Habibi:
It helps explain where you're coming from. You're addressing the literal question "Is declaring variables inside a method is efficent or declaring it outside is efficient." by focusing on the word "declare". I'm addressing it based on what I consider to be the interesting part: that is: "What are the Advs and Disadvs of both.". That's why my reply goes into the pros and cons, explores the ramifications of each, and gives examples of when one path or another might be appropriate.

I still think that it is essential to understand the difference between the declaration of a variable and the instanciation of an object. I think a little bit nitpicking is well advised on that score...
You are possibly right, though, that the OP was as interested in instanciation as in declaration - which I missed to consider.

Just different styles of helping people, nothing to get worked up about.

I am totally relaxed, thanks!

Hopefully, the original poster picked up something useful.

I hope so, too. Well, I *have* picked up something, anyway...

[Max Habibi]

It seems like part of your reply got snipped out.

As declaration happens at compile time, that most probably doesn't present any performance issue.
QUOTE]
It's not a matter of "when", but a matter "how much/How often".
Does that help?
M

[Ilja Preuss]

Originally posted by Max Habibi:
I say a variables is "the name given to " a variable, you say it's "a reference to" a variable. AFAIK, that's a slight variation in termanology.

No, I am saying a variable is a reference to *an object* (as long as it isn't primitive). Again, variables and objects are orthogonal concepts:

MyClass myObject; // here we declared a variable
new MyClass(); // here we instanciated an object
               // it will get gc'ed soon, as it doesn't get referenced
new MyClass().foo(); // here we called a method on a newly instanciated object without using a variable
myObject = new MyClass(); // here we instantiated a new object and assigned a reference to it to the already declared variable

[Ilja Preuss]

Originally posted by Max Habibi:

As declaration happens at compile time, that most probably doesn't present any performance issue.

It's not a matter of "when", but a matter "how much/How often".

If the "when" is answered "before runtime", then the "how often" is nonrelevant for runtime performance, isn't it?
Do you really care about compile time that much?

[Max Habibi]

I say a variables is "the name given to " a variable, you say it's "a reference to" a variable. AFAIK, that's a slight variation in termanology

Meant to write: I say a variables is "the name given to " an object, you say it's "a reference to" an object. AFAIK, that's a slight variation in termanology.

[Max Habibi]

Originally posted by Ilja Preuss:

MyClass myObject; // here we declared a variable
new MyClass(); // here we instanciated an object
               // it will get gc'ed soon, as it doesn't get referenced
new MyClass().foo(); // here we called a method on a newly instanciated object without using a variable
myObject = new MyClass(); // here we instantiated a new object and assigned a reference to it to the already declared variable

This is all pretty elementry, Ijla: I'm not sure what your point is.
Also, I wouldn't say that variables and objects are orthogonial concepts: but again, I would say that they are complementry. But that's just a matter of how one uses termonalogy. Let's not start start a thread on that.

[Max Habibi]

Originally posted by Ilja Preuss:

If the "when" is answered "before runtime", then the "how often" is nonrelevant for runtime performance, isn't it?
Do you really care about compile time that much?

It's not a matter of what I care about: it's a matter of answering the question. The second way is more memory intensive. That's all. It's probably a good idea to relax about this :-).