Is it unefficient in terms of computing performance when i use have/use methods with alot (more than hundred) parameters ?
I don't mean efficient in terms of maintainability, but only in "raw" computing performance :)
Is it unefficient in terms of computing performance when i use have/use methods with alot (more than hundred) parameters ?
I don't mean efficient in terms of maintainability, but only in "raw" computing performance :)
Theoretically, perhaps, since Java is pass-by-value, meaning that when a function is called, the JVM makes a copy of every parameter value and gives the copies to the function, so there may be some point at which the number of parameters has a non-negligible effect on execution time. But in practice, whenever possible, these copies are "shallow" copies, meaning that they're more like references, so there is very little time spent actually making the copies. So you would probably need a lot more than 100 parameters to have any noticeable impact on performance time.
In any case, even considering the performance time of something like this sounds very much like premature optimization. It is almost certainly not the bottleneck for your program, so it's not worth spending time on until you're certain that it's actually causing slowdown. If your program is unacceptably slow, investigate other possible sources of slowdown.
There is also, of course, as you mention, the issue of "maintainability." Why do you need hundreds of parameters for a single function? Are they complex parameters, such as ArrayLists of custom objects, or are they simple built-in data types? If the latter, why not consider packing them together into arrays, ArrayLists, and so on? Alternatively, why not break the function down into multiple functions? Modern computers are fast enough that for many (arguably most) purposes, programmer time is more valuable than processor time, so your first concern, when coding, should usually be whether what you're writing is understandable and well-written, not whether it's fast.
As the article below says, it would perform better with less parameters, but it's not a big performance hit. But you should consider passing an object.
http://www.dailyfreecode.com/forum/parameter-performance-21574.aspx
Well there will be a cost. All those parameters will have to be pushed onto the stack. I don't imagine it would cause trouble in terms of computing power unless it was in a heavy loop though.
Are you mad at a fellow programmer? Or making some kind of programatically created code?
To answer your question: no, passing 100 parameters won't incur a significant performance hit. Unlike another answer, I suggest not passing an object. If you do that, the code WILL become unmaintainable. I've seen maps full of parameters that nobody understands. Instead, use the best practices recommended by Joshua Block in Effective Java (Chapter 7, method signatures) to keep your number of parameters down to a reasonable level.
For example: break your method into multiple methods.
See this answer to a similar question:
I am currently reading the book entitled "Java: The Good Parts". It recommends that in general, passing interfaces is the way to go. I would suggest that you make an interface with the 100 parameters, and pass that instead of passing the 100 parameters. It will be a lot clearer what is going on in the future.
The biggest cost will be in the headache maintaining it, so far as I'm concerned. But there isn't a huge difference passing these parameters once, if that's all you are planning on doing.
Thats hard to answer, most people find more than a handful method parameters indicate a serious problem anyway.
There are some aspects though that, when you think about it, also indicate many methods parameters will have an effect on performance. Each method parameter occupies a slot on the stack (like a local variable would). By itself a slot is basically almost free, BUT when calling you method monster each parameter slot also must be populated. That means there is inevitably some READ operation to get a value for the slot by the caller and also a PUSH to the stack for said value.
So yes, each parameter has a small cost attached to it, and as a first approximation the cost is linear with the number of parameters.
Now, when you pull the parameter values from somewhere you effectively do more work than just passing a reference to said parameters - for example lets assume you had a method to calculate the area of a rectangle and write it with 4 parameters:
public int area(int x1, int y1, int x2, int y2) {
return ....;
}
Instead of
public class Rectangle {
int x1, y1, x2, y2;
public int area() {
return ....;
}
}
Now in the first case, you need to pull 4 ints and push them back to the stack, while to call the second case, you only need to pull the reference to the rectangle. Granted the area() method of rectangle still will have to pull its members, but you at least saved 3 stack pushes (with 100 parameters you probably can save more).
Also, a method with 100 parameters implies that its quite a big method, otherwise most parameters would not get used anyway and would just be a waste. A large method suggests a high complexity and this might interfere with the JIT's ability to generate good code. It is hard to demonstrate, but a straightforward example would be method inlining. The JIT has a limit for how much code it will consider for inlining, large methods are not candidates. To some degree, you can expect the JIT to deal best with commonly used idioms (optimizing the most common cases gives more bang for the effort, obviously), and 100 method parameters is definetly outside of commonly used.