Query regd. memory usage

[Sunil]

Hi ,

I have a method which takes a list of beans as parameter and does some
insertions into the database. I have something like this inside the
for loop:

for(int i=0;i<list.size();i++){
MyBean bean = new MyBean();
....................
....................
}


Initializing the bean inside the for loop is mandatory.
Will initializing the bean inside the for loop cause more memory
usage?
Or is this better?

MyBean bean = null;
for(int i=0;i<list.size();i++){
bean = new MyBean();
....................
....................
}
Which of the above two constructs is better?
My guess is both of them consume the same amount of memory. And there
is no difference in the performance either.

What do you think? Your suggestions are welocme.

Thanks & Regards,
Sunil.

 

[Andrew Thompson]

Sunil wrote:
...

What do you think? Your suggestions are welocme.

I think your benchmark times (with code) would be
a better approach to answering this question.

--
Andrew Thompson
http://www.athompson.info/andrew/

Message posted via JavaKB.com
http://www.javakb.com/Uwe/Forums.aspx/java-general/200705/1

 

[Matt Humphrey]

| Hi ,
|
| I have a method which takes a list of beans as parameter and does some
| insertions into the database. I have something like this inside the
| for loop:
|
| for(int i=0;i<list.size();i++){
| MyBean bean = new MyBean();
| ....................
| ....................
| }
|
|
| Initializing the bean inside the for loop is mandatory.
| Will initializing the bean inside the for loop cause more memory
| usage?
| Or is this better?
|
| MyBean bean = null;
| for(int i=0;i<list.size();i++){
| bean = new MyBean();
| ....................
| ....................
| }
| Which of the above two constructs is better?
| My guess is both of them consume the same amount of memory. And there
| is no difference in the performance either.

Your guess is right--there is virtually no difference to the two
constructions because both allocate the same number of bean objects--the
location of the declaration does not affect the time or memory.
Furthermore, if you are inserting into the database on each pass through the
loop, the network and disk traffic will far exceed anything you do in the
program.

If you determine through profiling that the list and MyBean are so large
that they're a problem, you could get allocate only one and reuse it.

MyBean bean = new MyBean ();
for (int i = 0; i < list.size(); i++) {
// set the full bean contents, apply and insert
}

Matt Humphrey (e-mail address removed) http://www.iviz.com/

 

[Lew]

| Hi ,
|
| I have a method which takes a list of beans as parameter and does some
| insertions into the database. I have something like this inside the
| for loop:
|
| for(int i=0;i<list.size();i++){
| MyBean bean = new MyBean();
| ....................
| ....................
| }
|
|
| Initializing the bean inside the for loop is mandatory.
| Will initializing the bean inside the for loop cause more memory
| usage?
| Or is this better?
|
| MyBean bean = null;
| for(int i=0;i<list.size();i++){
| bean = new MyBean();
| ....................
| ....................
| }
| Which of the above two constructs is better?
| My guess is both of them consume the same amount of memory. And there
| is no difference in the performance either.

Your guess is right--there is virtually no difference to the two
constructions because both allocate the same number of bean objects--the
location of the declaration does not affect the time or memory.
Furthermore, if you are inserting into the database on each pass through the
loop, the network and disk traffic will far exceed anything you do in the
program.

If you determine through profiling that the list and MyBean are so large
that they're a problem, you could get allocate only one and reuse it.

MyBean bean = new MyBean ();
for (int i = 0; i < list.size(); i++) {
// set the full bean contents, apply and insert
}

The decision of where to declare a variable, or where to reuse it, should not
be done on the basis of putative performance gains. You will get more by
tuning the garbage collector than by detuning an algorithm.

The decision of how to use a variable in your program should be based on
correctness, such as the proper scope for it.

Declaring the "bean" variable inside the loop limits its scope to the loop.
Declaring it outside the loop gives it wider scope. Wider scope can be bad if
it is too wide; it couples program segments together that should be independent.

Reuse can have unintended consequences, especially if you are careless about
clearing "old" data before reusing an object. Long-lived objects are GCed
differently from the kind of quick in-the-loop objects being discussed here.
Young-generation collections are very fast, since dead objects don't take GC
time and most of the objects in the "within-loop" declaration style will be dead.

Stop worrying about optimization and concentrate on correctness. Stick with
the within-the-loop declaration and re-allocation in each iteration, unless
scope demands that the variable be seen elsewhere.

 

[Sunil]

The decision of where to declare a variable, or where to reuse it, should not
be done on the basis of putative performance gains. You will get more by
tuning the garbage collector than by detuning an algorithm.

The decision of how to use a variable in your program should be based on
correctness, such as the proper scope for it.

Declaring the "bean" variable inside the loop limits its scope to the loop.
Declaring it outside the loop gives it wider scope. Wider scope can be bad if
it is too wide; it couples program segments together that should be independent.

Reuse can have unintended consequences, especially if you are careless about
clearing "old" data before reusing an object. Long-lived objects are GCed
differently from the kind of quick in-the-loop objects being discussed here.
Young-generation collections are very fast, since dead objects don't take GC
time and most of the objects in the "within-loop" declaration style will be dead.

Stop worrying about optimization and concentrate on correctness. Stick with
the within-the-loop declaration and re-allocation in each iteration, unless
scope demands that the variable be seen elsewhere.

Thanks Lew and Matt for your valuable responses.