File APIs for Java Developers
Manipulate DOC, XLS, PPT, PDF and many others from your application.
The moose likes Performance and the fly likes is using 'this' so un-justifiable in the context of performance Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login
JavaRanch » Java Forums » Java » Performance
Bookmark "is using Watch "is using New topic

is using 'this' so un-justifiable in the context of performance

Ranga Kalidindi

Joined: Mar 04, 2005
Posts: 17
I recieved a few code review comments from one of my designers. Found one of them interesting and am curious to have our forum members views on this.

The review comments says "...There is no justifiable reason for using this other than to pass a reference. The problem with using this is fairly straight forward: a double reference creates more work and impedes performance. this is a pointer to the object. this.something means that the JVM will have to go to the stack via the reference and retrieve the object and then reference the method provided. Since all properties and methods are visible through scope, this.something is creating more work for no reason. Hence the statement: do not use it. Some feel that = incomingPropertyValue is a justifiable reason for using it since the names are the same. This is not justifiable: rename the incoming variable, do not use this.."

Probably I was over-using 'this' in my code.
But is 'this' really that bad ?
Jim Yingst

Joined: Jan 30, 2000
Posts: 18671
No. In fact it sounds like your code reviewer has little or no idea what they're talking about. Consider the following:

If you disassemble this this with javap -c Test, you get:

From this we can see that setX1() and setX2() are exactly identical. The use of "this" in a standard setter method makes no difference at all.

It's possible that there are some other contexts in which using "this" might make some difference. But I think your code reviewer has a grossly exaggerated impression of how important this effect might be.

Now if we ignore performance issues, then there may be good reasons to discourage or even forbid people from using local variable names which duplicate field names. This sort of name duplication (hiding) can be very confusing if the reader does not notice it. For simple setter methods it's such a common idiom, and the methods are so extremely simple, that the chance of introducing a bug because of this is fairly small. Code like "this.x = x" is very common, and probably simple enough that it's not a significant risk of bugs. Still, I understand if someone thinks that it's best to always avoid name hiding. Such an attitude is perhaps a bit overly paranoid, but not completely unjustified.

However, if your code reviewer insists on citing performance as the reason for this rule - there's really no justification for this; the reviewer simply doesn't understand how Java works.

Of course, if this is someone you need to work with in the future, then you should be careful about how agressively you point this out. However in terms of your own understanding of how the code works: don't pay much attention to this reviewer in the future. They don't seem to be a reliable source of information.
[ October 26, 2005: Message edited by: Jim Yingst ]

"I'm not back." - Bill Harding, Twister
Paul Sturrock

Joined: Apr 14, 2004
Posts: 10336

Sounds suspect to me. "Early optimizations" are always a bad thing. The way I understand it, the this keyword is a way of explicitly using a reference to the current object that exists anyway, its not a "double reference" (whatever that is), its the same reference. "all properties and methods are visible through scope" is true only because this is used implicitly. I would very much doubt you'll see any performance difference using it in this way or not. There is an easy way to find out for sure - write a couple of performance tests and see.

JavaRanch FAQ HowToAskQuestionsOnJavaRanch
Jeff Albertson
Ranch Hand

Joined: Sep 16, 2005
Posts: 1780
I would go further than Jim: if the other people you have to work with
are as stupid as the "designer" who reviewed your code, I would look for
another job where people don't speak out of their ssh le like him.

But in the meanwhile, you should humbly show this reviewer the byte code
that Jim used to illustrate the point that there is no performance issue
here. Show the byte code and quietly ask the reviewer to point out the
place where performance is impeded, because you are having trouble seeing
it, but he is so wise and insightful, he will be able to show you the byte
code which proves "this" is bad.
[ October 26, 2005: Message edited by: Jeff Albrechtsen ]

There is no emoticon for what I am feeling!
Ilja Preuss

Joined: Jul 11, 2001
Posts: 14112
Full agreement with Jim, Paul and Jeff. Sounds like a learning opportunity for the reviewer. Don't be too hard with him - we all do mistakes...

Anyway, moving to our Performance forum...

The soul is dyed the color of its thoughts. Think only on those things that are in line with your principles and can bear the light of day. The content of your character is your choice. Day by day, what you do is who you become. Your integrity is your destiny - it is the light that guides your way. - Heraclitus
Mr. C Lamont Gilbert
Ranch Hand

Joined: Oct 05, 2001
Posts: 1170

I am also in agreement that particular person had NO idea what he/she was talking about.

Furthermore, _always_ use 'this' in inner classes, even when calling methods. If you don't qualify every call to a class member in an inner class you can never be sure if its calling on the outerclass or the inner class heirachy.

I make my calls either OuterClass.this.method() or InnerClass.this.method(). One it makes it clear which method you are trying to call, two it ensures that if someone later adds a method to the super class of the inner class, your program won't suddenly break because the inner class is calling a different method now...Either that or don't use non-static inner classes.
Ilja Preuss

Joined: Jul 11, 2001
Posts: 14112
Originally posted by Mr. C Lamont Gilbert:
Either that or don't use non-static inner classes.

Or write unit tests for your classes...
Ranga Kalidindi

Joined: Mar 04, 2005
Posts: 17
Thank you very much for all the views.

And thanks Jim about letting me know 'how we ourselves can check for deciding on which way to go'.

Certainly I am not going to be hard on my reviewer. He has made many other good/valuable suggessions and I have accepted them and made changes. For this one, I found it little strange. So thought I might clarify for myself about this.

Thanks Java Ranch.
Stuart Ash
Ranch Hand

Joined: Oct 07, 2005
Posts: 637
Alright, so what was your reviewer's reaction?? :roll:

I guess for a lot of developers in the industry, this forum is a useful forum (oops) to post such "controversial" points and get clarification.

That way, one can convince another team member, peer or senior, about the correct way, without appearing arm-twisty.

ASCII silly question, Get a silly ANSI.
Ranga Kalidindi

Joined: Mar 04, 2005
Posts: 17
Replied for that point that "I disagree on that one relating - the use of 'this' with performance. And changing code to remove 'this' would make a code change in about 30 classes - for a reason which doesnot convince me would make any performance improvement".
He is fine without a code change on this one.

Thanks again guys.

[ October 31, 2005: Message edited by: Ranga Kalidindi ]
I agree. Here's the link:
subject: is using 'this' so un-justifiable in the context of performance
It's not a secret anymore!