Coding performance

Question

Hi
I have two questions regarding the performance issue:
Q1.
I have a "Collection" object, each element inside the "Collection" is a class object, then I am going to tranverse the "Collection" to an array object and pass an array object to the function. In terms of performance issue, is it a good way to do so?
Collections c = Obj.getCollection();
//calling a function
function((Obj[]) c.toArray());
Q2.
Which way is better to parse an object?
Obj a = obj.getA();
//calling function
setA(a);
or
setA(obj.getA());
Thanks!

Answer 1

user978043 wrote:
Hi
I have two questions regarding the performance issue:
Q1.
I have a "Collection" object, each element inside the "Collection" is a class object, then I am going to tranverse the "Collection" to an array object and pass an array object to the function. In terms of performance issue, is it a good way to do so?
Collections c = Obj.getCollection();
//calling a function
function((Obj[]) c.toArray());
It almost certainly won't matter. In the general case, tiny little things like that have no visible effect on performance.
The real question here is not "how will it affect performance?" but "what do I need?" or "what's the sensible deisgn?" Do you need an array? If so, then you have no choice, and you have to call toArray(). But if you don't need an array--that is, if you control function()--why not just have it take a Collection instead?
In other words, the choice to use a collection or an array is a design choice, not a performance choice. (There are exceptions to this, but you'll know them when you run across them, which won't happen during your early academic career.)
Q2.
Which way is better to parse an object?
Obj a = obj.getA();
//calling function
setA(a);
or
setA(obj.getA());There's no parsing going on there.
Again, you will never see a performance difference here. If you're going to use the result of getA() more than once, then store it in a variable. If you're only going to use it once, you can just call setA(obj.getA()) if you find its compactness easier to read. Note that in some cases this can make debugging more difficult, and for all but very simple expressions like that, it gets hard to read very quickly.
Don't worry about piddly little microoptimizations for performance. That's a waste of time, and it teaches you to focus on the wrong things. Performance comes from appropriate design, data structures, and algorithms, not from counting CPU cycles for variable assignments.