Results 1 to 18 of 18
  1. #1
    raki.seattle is offline Member
    Join Date
    Aug 2009
    Posts
    2
    Rep Power
    0

    Default Creating multiple local references & impact on performance

    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?

  2. #2
    r035198x is offline Senior Member
    Join Date
    Aug 2009
    Posts
    2,388
    Rep Power
    8

    Default

    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.

  3. #3
    dlorde is offline Senior Member
    Join Date
    Jun 2008
    Posts
    339
    Rep Power
    7

    Default

    Quote Originally Posted by r035198x View Post
    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.

  4. #4
    r035198x is offline Senior Member
    Join Date
    Aug 2009
    Posts
    2,388
    Rep Power
    8

    Default

    I guess readability and maintainability can also be relative.

  5. #5
    dlorde is offline Senior Member
    Join Date
    Jun 2008
    Posts
    339
    Rep Power
    7

    Default

    Quote Originally Posted by r035198x View Post
    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?"

  6. #6
    mrmatt1111's Avatar
    mrmatt1111 is offline Senior Member
    Join Date
    Aug 2009
    Location
    San Jose, CA, USA
    Posts
    320
    Rep Power
    6

    Default

    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.
    My Hobby Project: LegacyClone

  7. #7
    r035198x is offline Senior Member
    Join Date
    Aug 2009
    Posts
    2,388
    Rep Power
    8

    Default

    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).

  8. #8
    dlorde is offline Senior Member
    Join Date
    Jun 2008
    Posts
    339
    Rep Power
    7

    Default

    Quote Originally Posted by r035198x View Post
    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.

  9. #9
    r035198x is offline Senior Member
    Join Date
    Aug 2009
    Posts
    2,388
    Rep Power
    8

    Default

    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.

  10. #10
    dlorde is offline Senior Member
    Join Date
    Jun 2008
    Posts
    339
    Rep Power
    7

    Default

    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.

  11. #11
    r035198x is offline Senior Member
    Join Date
    Aug 2009
    Posts
    2,388
    Rep Power
    8

    Default

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

  12. #12
    dlorde is offline Senior Member
    Join Date
    Jun 2008
    Posts
    339
    Rep Power
    7

    Default

    Quote Originally Posted by r035198x View Post
    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?

  13. #13
    r035198x is offline Senior Member
    Join Date
    Aug 2009
    Posts
    2,388
    Rep Power
    8

    Default

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

  14. #14
    dlorde is offline Senior Member
    Join Date
    Jun 2008
    Posts
    339
    Rep Power
    7

    Default

    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.

  15. #15
    raki.seattle is offline Member
    Join Date
    Aug 2009
    Posts
    2
    Rep Power
    0

    Default

    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
    ------------
    ------------
    ------------
    }
    }

  16. #16
    r035198x is offline Senior Member
    Join Date
    Aug 2009
    Posts
    2,388
    Rep Power
    8

    Default

    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.

  17. #17
    Tolls is offline Moderator
    Join Date
    Apr 2009
    Posts
    11,949
    Rep Power
    19

    Post

    Quote Originally Posted by raki.seattle View Post
    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.

    Java Code:
    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.

  18. #18
    Steve11235's Avatar
    Steve11235 is offline Senior Member
    Join Date
    Dec 2008
    Posts
    1,046
    Rep Power
    7

    Default

    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

Similar Threads

  1. Impact 0.7.5
    By JavaBean in forum Java Software
    Replies: 0
    Last Post: 07-12-2007, 07:45 PM
  2. Impact 0.7.4
    By Jamie in forum Java Software
    Replies: 0
    Last Post: 06-14-2007, 02:57 PM
  3. Impact 0.7.3
    By levent in forum Java Software
    Replies: 0
    Last Post: 06-03-2007, 09:33 AM

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •