I know you've already gotten several answers and seem done with the conversation but after looking at this a couple of comments occurred to me.
Terry Tucker wrote:Is there any performance hit as a result of calling the method repeatedly as compared to declaring a single reference to the object and using it repeatedly?
As you've already found out, yes. Any code that isn't necessary for a correct result will at best be optimized out by your compiler and at worst will slow down your application.
At least one other person has already correctly pointed out that it's rarely necessary or beneficial to try to identify and eliminate performance problems in advance, but I can still think of a couple of reasons to remove the offending code in this specific case. For one thing, the extra method call would make debugging marginally more complex and time-consuming. More importantly, though, the method call is entirely unnecessary: what you have is an object with an instance method that returns a reference to . . . itself. In other words, the method is nonsensical because by definition the fact that you're able to call it means that you already have the information it will return. As someone already pointed out a good, clean design is preferable to one that seems to provide better performance, but in this case it's not a trade-off: the cleaner design will also yield better performance.
I say all this, of course, without any context beyond what you've provided. The answer might be different if, for example, GetObject is extended and its getObject() method overridden, but based on what you've shown here the method call is essentially what we used to call a "no-op": it does nothing but take up space and should be removed.