Java函数参数与getter的比较，是否有优势？

Question

Consider the two following situations:

void Foo1(int a, int b, int c, int d) {
    return a + b + c + d;
}

versus

void Foo2(MyArgs args) {
    return args.getA() + args.getB() + args.getC() + args.getD();
}

Is there a speed advantage to either case? I have read that the JIT will inline getters. So is there more overhead in passing multiple objects versus a single object to a function, or is this optimized away too?

I am specifically looking for answers about speed only. I am writing some code to recursively search a very large tree, so this type of call will be used many, many times. My function must return as quickly as possible before a timeout occurs. I would like to search as far as possible into the tree.

If the speed is essentially the same (ie JIT makes both functions essentially equivalent), then I can choose based on readability and maintainability.

BTW, is there a magic number of parameters in Java that if you stay below, it is okay but if you go over it is bad? For instance I have worked on machines that if you have 4 or less parameters, then they will be stored in registers, where as more than 4 will get pushed onto the stack?

BTW, I am still a Java novice...

Also, before you answer "Premature", I understand premature optimization. I am now in the optimization phase. I have written my recursive function that I am trying to optimize, TIA.

Answer 1

You seem to be in the design phase, not in the optimization one. A method signature is the last thing you would ever check when optimizing.

The method signature is decided entirely by what it needs to process. If those numbers are related, it does make sense to have a wrapper object for them and find a meaningful name for that wrapper class in your domain. The main advantage is that when you'll need to add some extra fields to that object (or remove some), you won't need to touch your method signatures. Moreover, you will most likely find other usages for that wrapper object, since it's something that has a meaning in your domain.

In terms or performance, there's an overhead of creating a holder object so if those numbers don't naturally belong together, it's a bad idea to define a container for them. But if you know they don't belong together, and yet your method needs them all, then you will sort this out from the design phase (by simply listing them individually in the method signature).

Long story short, if you end up modifying method signatures in the "optimization phase", that's a strong signal that you've skipped the design phase.