5

I am still a beginner to java and I have a question on an efficient way to pass in parameters. When passing in objects in a method is it more efficient to pass in portions of an object or does it not matter at all? for example, lets say I have a Person object which has several attributes (name, height, gender, location, hairColor etc.) and I have a method which needs to work on two of these attributes. When I pass the info into the method, does it save me memory, process time etc to only pass in the needed info (like name and location) or is it the same as just passing in the whole person object?

is:

public void getNamePlace(String name, String location){
\\\\work here
}

any different efficiency-wise than:

public void getNamePlace(Person person){
\\\\work here and get the name location in the method
}

Thanks a lot for the help. I'm sorry if it is a dumb question but I'm trying to figure out the best mentality to approach this. Thank you.

p.s. I am thinking more on the method call itself. How does it work. In isolation, is:

public void getNamePlace(String name, String Location) --> More bits passed around and memory used than --> public void getNamePlace(Person person)

M1 Garand
  • 99
  • 7
  • 1
    This is worrying about the wrong thing at the wrong time. They are both just "as efficient" and there is **no** performance issue/concern here. Period. Instead, write the code that makes more sense .. (even if it took another kilobyte to invoke the method, but in reality it is < 8 bytes per argument, *it just wouldn't matter*.) –  Aug 16 '12 at 18:23
  • If you do go the composite route (ie one object), I highly recommend you make that object immutable for thread safety: http://docs.oracle.com/javase/tutorial/essential/concurrency/imstrat.html . Immutable objects are also less overhead to create (no setters). – Adam Gent Aug 16 '12 at 18:56
  • @AdamGent I prefer immutable objects, but not necessarily for "thread safety" (most of my code does not involve threads or has strict contracts defined) nor "less overhead" (in source code it's just a template/good IDE, the Class definition is slightly bigger sure, but instantiation is the same) .. immutable objects simply make a program easier [for me] to reason about. And I am lazy. –  Aug 16 '12 at 18:58
  • @pst I actually didn't mean to bother you. I meant add the comment for the OP as he might not know about it. I also make immutable objects all the time for reasons other than thread-safety. And your right about the creation. I was thinking of another language (vtable-like creation in languages like Python). – Adam Gent Aug 16 '12 at 19:03
  • @AdamGent I was just pointing out that there is a more fundamental reason to use immutable types -- not that the reasons listed aren't benefits, but there is a more immediate result: easier to think/reason about code :) –  Aug 16 '12 at 19:08
  • @AdamGent Tyvm. Ill look at it. Also thanks for giving me the correct term "Composite". Now I at least know what to search for. – M1 Garand Aug 16 '12 at 19:11
  • @M1Garand I actually have no idea if "*composite*" is the official term. I have heard some say *container*. Java has lots jargon overlap. Immutable object might be a better term. – Adam Gent Aug 16 '12 at 19:14

8 Answers8

10

You're passing reference values. The more values you pass, the more work is being done.

Is it a measurable difference? Technically, yes–but miniscule in the extreme (e.g., another parameter is another bytecode, and that's all. Vanishingly small difference in performance and class size.)

Is it an appreciable difference? No.

The mentality here is that premature optimization, particularly at this level, isn't something to deal with.

Others have pointed out there are readability and data issues that are more important.

Dave Newton
  • 158,873
  • 26
  • 254
  • 302
  • 2
    For a *very* small value of "measurable" that is quickly saturated into nothingness .. –  Aug 16 '12 at 18:27
  • Thank you all for the help. It is much appreciated. :) – M1 Garand Aug 16 '12 at 18:51
  • Also relevant is: http://stackoverflow.com/questions/1109995/do-getters-and-setters-impact-performance-in-c-d-java – Adam Gent Aug 16 '12 at 19:06
  • partly untrue, if the method is not inlined and having enough (depends on the CPU arch) parameters they are to be passed by the stack not CPU registers. – bestsss Aug 22 '12 at 08:46
4

It "doesn't matter at all". In Java you only pass the reference of the object (as a value) to the function. It's a very small data type and it tells the VM where the object is located in memory.

Take a look at Is Java "pass-by-reference" or "pass-by-value"? for a very good answer ;)

Community
  • 1
  • 1
Samuel
  • 16,923
  • 6
  • 62
  • 75
4

When you use this:

public void getNamePlace(Person person){
   \\\\work here and get the name location in the method
}

nothing actually gets passed to the method except a reference (a "pointer" in a loose sense) to the actual object of type Person. No copying of members takes place, as you are instead instructing the method "you can find all you need at this memory location".

So technically passing a limited number of fields from person is actually worse than passing "the entire person" (although the difference is not noticeable anyway). :)

Tudor
  • 61,523
  • 12
  • 102
  • 142
3

Objects in java are passed by reference. The short answer is to just pass your objects.

The long answer is that object references are either 32 or 64 bits, depending on your java installation. A 64 bit quantity is twice as large as the JVM's typical padding size (which is often 32 bits even on 64 bit systems under some circumstances). There is a small amount of overhead associated with dereferencing the reference, but the JIT compiler will usually optimize it to a constant amount rather than a repeated hit. Furthermore, you will always have to dereference it sometime, either inside the function or outside. You might as well just save on the stack space and pass the object by reference.

Wug
  • 12,956
  • 4
  • 34
  • 54
  • 1
    Unfortunately "objects .. are passed by reference" (which means, based on the explicit noun of "objects" and the "ed" modifier, the reference [values] are passed) is very similar to "pass by reference" or "call by reference" which means something else .. for this reason I try to avoid the phase, except when I am talking about "call by reference" semantics. –  Aug 16 '12 at 18:30
  • @pst: Great distinction, I'll delete my comment. – Chris Dargis Aug 16 '12 at 18:33
2

You're passing around an extra address using getNamePlace(String,String) instead of getNamePlace(Person).

Java will not make a copy of the Person object when passing it; it passes the reference.

Similarly, Java will not make a copy of the Strings when passing them; it passes the references.

Will you notice a significant performance difference? No.

frianH
  • 7,295
  • 6
  • 20
  • 45
Matt
  • 4,515
  • 5
  • 22
  • 29
2

It doesn't matter at all considering time and efficiency.

But it does matter if you want to write readable code. - It's always nice to group logically connected items, as object that they represent

for example:

writeLetterTo(person);

is much better than that:

writeLetterTo(name, surname, address, city, country);

if only all those parameters can be taken somehow from person object.

Another example:

addTwoPionts(x1, x2, y1, y2); // ugly
addTwoPoints(point1, point2); // far better
dantuch
  • 9,123
  • 6
  • 45
  • 68
  • 1
    It goes beyond just readable code. If you wanted to enforce certain constraints on those values from within the Person class, you could no longer do that because you have just given away your data. Also, primitives aren't passed by reference, so if those parameters were modified in the function and should be reflected in the Person instance, that can no longer happen. There is a much bigger difference between passing in an Object which has data members, and just directly passing in the data members themselves. – kurtzbot Aug 16 '12 at 18:31
  • @kurtzbot you're definitely right, so thanks for metioning it. Anyway side effects in methods should be avoided. – dantuch Aug 16 '12 at 18:34
  • @kurtzbot Consider making your comment an answer. I'll proudly upvote it :) – dantuch Aug 16 '12 at 19:00
2

Apart from the method parameters, there are a couple of things you should tweak:

public void getNamePlace(Person person){
    \\\\work here and get the name location in the method
}

to get the habits right

  • getNamePlace method name when it returns nothing is not convention compliant. getXXXX should return the value.
  • Since getNamePlace will operate on Person so it should be defined in the class itself and then you need not to pass any parameters.
  • Finally to answer your question, you shouldn't bother too much about such micro-optimization so initially in language learning graph... It hardly makes any difference.
Bharat Sinha
  • 13,973
  • 6
  • 39
  • 63
  • Ok, thanks for the help. was just trying to get it down. Really didn't expect much traffic on this one. Thank you I will remember that. Though it is apparent the efficient difference is very small I asked more as a "how does java actually work?" I am trying to learn more about the guts of Java and not just save a nanosecond. – M1 Garand Aug 16 '12 at 18:49
  • @M1Garand, those advices are beyond Java as single language. They are common to all (I hope!) programming languages, so remember them well :). – dantuch Aug 16 '12 at 18:53
  • Good to know. I will heed the advice. Thank you both. – M1 Garand Aug 16 '12 at 19:28
1

I personally wouldn't be too concerned with this. If you are really concerned with performance that much you probably should look at using a lower level language. As others have said, there isn't really any performance difference between the two especially when it comes to just passing variables.

If you are truly having performance issues I would suspect there are many other places in your code that are slowing you down instead of parameter passing.

Ian Dallas
  • 12,451
  • 19
  • 58
  • 82