7

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 :)

Nick Russler
  • 4,608
  • 6
  • 51
  • 88
  • 12
    That sounds crazy.. 100 method parameters??? I almost had a minor heart attack. – Rohit Jain Dec 07 '12 at 18:10
  • what do you do with 100 params in a method?? you should have maximum 3. – Ioan Dec 07 '12 at 18:11
  • @loan.. Though there is no such standards defined for maximum parameters. – Rohit Jain Dec 07 '12 at 18:11
  • 1
    @Ioan Three is a bit too harsh, but I agree, 100 is way over most limits. – Sergey Kalinichenko Dec 07 '12 at 18:11
  • 1
    That many parameters begs for them to wrapped in a Hash or as a Class instance. 100 is beyond imaginable. – Wayne Weibel Dec 07 '12 at 18:13
  • 1
    Of course this is an extreme case, but i still want to know if the performance is affected in some ("non-linear") way :) – Nick Russler Dec 07 '12 at 18:13
  • Most probably you will not face such situation where you are going to have 100 or more parameters in a method, but yes it will not make any performance issue as those are local variables to method ans are created in stack. – Android Killer Dec 07 '12 at 18:14
  • I doubt it would be affected in a non-linear way. Each parameter is pushed onto the stack, which is a very efficient operation. – jalynn2 Dec 07 '12 at 18:15
  • It is inefficient in the fact that it will take you forever to type out 100 parameters. And also in that it will take you forever to memorize 100 parameters. Although, if you merged everything into one method (horrible design btw) performance wouldn't take a hit (actually would probably increase) – Jimmt Dec 07 '12 at 18:15
  • @Rohit Jain : Yes of course, you guys are right, there are no standards, but for better readability and good maintenance, and keeping in mind that a method should do only one thing.. I think that three should be enough. – Ioan Dec 07 '12 at 18:15
  • 1
    No performance hit if the method is called singularly, but imagine what would happen to the stack if that method were called recursively! – Wayne Weibel Dec 07 '12 at 18:16
  • An useless question: Nobody would pass 100 params to a method, because nobody could maintain that. – AlexWien Dec 07 '12 at 18:47
  • What's wrong with the question? A logging method could potentially have multiple overloads for MANY arguments if you don't want to use var args. – Pavel P May 04 '13 at 01:42

6 Answers6

4

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.

Kyle Strand
  • 15,941
  • 8
  • 72
  • 167
  • 1
    What would happen if that method would call itself recursivly, would this "shallow" copy mechanism still prevent an excessive usage of ram ? – Nick Russler Dec 07 '12 at 18:24
  • RAM really shouldn't be involved; the memory where function calls are actually happening should be entirely on the processor chip. Still, that's actually kind of an interesting question. Some languages, such as Scheme, require their implementation to support "tail-call optimization," which means that if a function calls another function as its last statement and returns the value returned by that function, then the stack frame used by the calling function is simply replaced by the new stack frame, which prevents it from eating up any more memory at all. The JVM, however, does not support this. – Kyle Strand Dec 07 '12 at 18:36
  • http://stackoverflow.com/questions/105834/does-the-jvm-prevent-tail-call-optimizations – Kyle Strand Dec 07 '12 at 18:36
  • @KyleStrand Last time I checked the stack was still mapped to RAM, it may be a little misleading to generally imply recursion is happening completely inside the processor. – Durandal Dec 07 '12 at 18:38
  • Okay, yes, sorry, my mistake. – Kyle Strand Dec 07 '12 at 18:45
3

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

Peter Rasmussen
  • 16,474
  • 7
  • 46
  • 63
1

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?

vextorspace
  • 934
  • 2
  • 10
  • 25
1

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:

best practice for passing many arguments to method?

Community
  • 1
  • 1
Diego Basch
  • 12,764
  • 2
  • 29
  • 24
  • 1
    you wrote " I suggest not passing an object" typo? He should pass an param object instead of 100 params – AlexWien Dec 07 '12 at 18:46
  • No, he shouldn't. Those param objects tend to grow and become monsters that nobody understands. It takes a lot of discipline to make sure every parameter in that object is valid and properly documented. I've seen this too many times over the years. – Diego Basch Dec 07 '12 at 18:51
  • 1
    passing 100 parameters is even worse, you cannot detect if you missplaced the position 97, and 98 which are both int. – AlexWien Dec 07 '12 at 18:56
  • 1
    Yes, but you shouldn't pick the lesser evil when there are better solutions. Read the pertinent chapter of Effective Java if you haven't. – Diego Basch Dec 07 '12 at 19:00
0

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.

PearsonArtPhoto
  • 38,970
  • 17
  • 111
  • 142
0

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.

Durandal
  • 19,919
  • 4
  • 36
  • 70