Creating multiple local references & impact on performance

[raki.seattle]

Hi, I am trying to how following two statements are interpreted by Java compiler and which one is a better practice. It would be really helpful if you can provide some documentation links about your opinion.

Consider following 2 classes...
public class ClassA {
int x;
double y;
public ClassA( int x, double y ) {
this.x = x;
this.y = y;
}
}

public class ClassB {
ClassA obj;
public ClassB( ClassA obj ) {
this.obj = obj;
}
}

Is there any difference between
public method(...) {
...............
...............
ClassA objA = new ClassA( 12, 35.0 );
ClassB objB = new ClassB( objA );
...............
...............
}
and
public method(...) {
...............
...............
ClassB objB = new ClassB( new ClassA( 12, 35.0 ) );
...............
...............
}

in terms of memory used?

[r035198x]

Both create the same number of objects. The first creates a extra reference to the object of type ClassB. If that reference immediately goes out of scope then they shouldn't be any memory use discrepancies. If the reference lingers then it will stop the Object from the gc-ed.
You generally don't want to create references that you don't need.

[dlorde]

You generally don't want to create references that you don't need.

This is true of course, but the question is what constitutes 'need'. Readability and maintainability are important, and I think this is a 'need' that should be taken into account. Code is often more readable and maintainable when complex expressions are broken down into a number of simpler expressions - which typically involves additional references. As you say, these temporary references will not generally have any significant effect on memory use.

[r035198x]

I guess readability and maintainability can also be relative.

[dlorde]

I guess readability and maintainability can also be relative.

Yes, it's a judgement call - experienced developers should cope with complex expressions better than novices - but there are de-facto standards that point to the importance of readability and maintainability: e.g. the Java Naming Conventions are pretty much universal, and the Java Coding Conventions really should be ;)

A large part of the reason for developing Java itself was to simplify code and make it more readable and maintainable... I suppose another obvious example is the [CODE]...[/CODE] tags for forum readability.

My point is really that this aspect of code is often neglected by budding developers, and some are tempted to demonstrate proficiency with dense and impenetrable code - hence Brian Kernighan's(?) quote: "Everyone knows that debugging is twice as hard as writing a program in the first place. So if you are as clever as you can be when you write it, how will you ever debug it?"

[mrmatt1111]

In your example:

The former has one extra reference on the method's memory stack which would be 32-bits or 64-bits depending on the system, but that is beyond trivial. I would go with the one that is more readable.

[r035198x]

I'm sure we all appreciate the importance of code conventions and such.
In this particular example there is no need for creating the extra variable at all and it does not make the code any more readable. As I already mentioned you run the risk of sacrificing correctness (the lingering variable that unnecessarily stops gc-ing).

[dlorde]

In this particular example there is no need for creating the extra variable at all and it does not make the code any more readable. As I already mentioned you run the risk of sacrificing correctness (the lingering variable that unnecessarily stops gc-ing).

I agree - in this particular example, it doesn't make much difference to readability. But does using a temporary reference there stop gc-ing? Surely it will be optimized away by a modern compiler, and even if not, it will become eligible at the end of the method. AIUI, standard gc passes don't occur that often.

[r035198x]

No it does not stop gc if the reference immediately goes out of scope as I have already said earlier. I merely pointed out that having the unnecessary reference leaves a hook that can be (ab)used to stop gc-ing of the object when it should be.

[dlorde]

OIC - yes, agreed :cool:

I have seen code where all variables are nulled after use, but that does seem like overkill - not a substitute for careful resource management.

[r035198x]

It is overkill except in only one extremely rare case probably not even worth mentioning.

[dlorde]

It is overkill except in only one extremely rare case probably not even worth mentioning.

Doh! now you've made me curious... I've seen memory leak problems with statics and collections and short-lived observers/listeners of long-lived subjects, but they're not so rare - so what is this extremely rare case?

[r035198x]

Read the section on Invisible Objects A.3.3 in this text.

[dlorde]

Aha, nice one! Unfortunately, it probably wouldn't be quite so easy to recognise 'in the field' as the tidy little example given. Well worth remembering though. Thanks.

[raki.seattle]

Thanks everyone, for your thoughts. As mentioned in one of the posts, I understand that one extra reference is created in example 2. However the local reference gets GCed as soon as it comes out of scope. To my knowledge, there could be a time lag between an object "is marked for garbage collection" and "it actually gets garbage collected". If I am correct, what magnitudes of time lag it could be (in milliseconds or more)? Also consider following example and throw some light on how effective it could be, if I nullify classAObjects variable after loop-1. Thanks in advance.

public static List<ClassB> myMethod(...)
{

// I get atleast 100 objects of type ClassA returned from following method
List<ClassA> classAObjects = FunctionalClass.getClassAObjects();

// I need to return classBObjects after copying some properties from
// classAObjects and performing some business logic on classBObjects
List<ClassB> classBObjects = new ArrayList<ClassB>();

// Loop-1

for( ClassA classAObject : classAObjects ) {

ClassB classBObject = new ClassB();
// Copy Properties from ClassAObject to ClassBObject
------------
------------
------------
classBObjects.add( classBObject );

}

// I don't actually need classAObjects from here...
// Loop-2

for( ClassB classBObject : classBObjects ) {

// Business Logic
------------
------------
------------

}

}

[r035198x]

You can't know for sure how long it will take between an object being marked for gc and actually getting gc-ed. In fact you can't know for sure if an object will ever be garbage collected.
You can't nullify classAObjects variable after loop-1 because it's declared in the loop and is out of scope after loop-1. Nullifying inside loop-1 as the last statement of the loop is possible but completely useless.

[Tolls]

Thanks everyone, for your thoughts. As mentioned in one of the posts, I understand that one extra reference is created in example 2. However the local reference gets GCed as soon as it comes out of scope. To my knowledge, there could be a time lag between an object "is marked for garbage collection" and "it actually gets garbage collected". If I am correct, what magnitudes of time lag it could be (in milliseconds or more)? Also consider following example and throw some light on how effective it could be, if I nullify classAObjects variable after loop-1. Thanks in advance.

Is the List<ClassA> built in the getClassAObjects() method? If not, and it's simply returning a prebuilt List attribute (well, static in this case) then nullifying the reference will have absolutely no effect.

Secondly, if you find yourself nullifying references in some attempt to preempt the garbage collector then you're doing something wrong. There may be examples, but they are few and far between and you generally shouldn't be coding for them.

Finally, you're doing too much in that method. This can be broken down into a buildClassBList(), and a processClassBList(), thus removing any concerns about the life of the classAList.

public static List<ClassB> myMethod() {
	// I don't actually need classAObjects from here...
	// Loop-2
	List<ClassB> classBObjects = buildClassBList();
	processClassBList(classBObjects);
	return classBObjects;
}
	
private static void processClassBList(List<ClassB> classBObjects) {
	for (ClassB classBObject : classBObjects) {
		// Business Logic
	}
}

private static List<ClassB> buildClassBList()
{
	// I get atleast 100 objects of type ClassA returned from following
	// method
	List<ClassA> classAObjects = FunctionalClass.getClassAObjects();
		// I need to return classBObjects after copying some properties from
	// classAObjects and performing some business logic on classBObjects
	List<ClassB> classBObjects = new ArrayList<ClassB>();
	// Loop-1
	for (ClassA classAObject : classAObjects) {
		ClassB classBObject = new ClassB();
			// Copy Properties from ClassAObject to ClassBObject

		classBObjects.add(classBObject);
	}
	return classBObjects;
}

Essentially code so you don't have to faff about with trying to outthink the gc. This generally means coding short and simple methods. Conveniently this also means you're writing code that's far more readable and maintainable.

[Steve11235]

My only thought, after 20 years of coding, is this: Don't spend time with trivial optimizations. Do whatever is the most simple from a developer's perspective. I have wasted countless hours unknotting useless optimizations while cursing the original developer the whole time.

Here's an old military acronym: KISS. Keep It Simple, Stupid