Java - Will inlining code have benefits?

Question

I've done a bit of research but I mostly see c++ answers. The closest I've come to is this. I also saw this page but it doesn't really explain anything.

Are there any advantages if I use the second piece of code? Will there be noticable performance differences? What about memory? What if it's done repetitively?

Right now I have this function. I'm sure the benefit of this is code readability:

private static Bitmap resize(Bitmap image, int maxWidth) {
    float widthReducePercentage = ((float) maxWidth / image.getWidth());
    int scaledHeight = Math.round(image.getHeight() * widthReducePercentage);

    return Bitmap.createScaledBitmap(image, maxWidth, scaledHeight, true);
}

Now, I have this second snippet of code:

private static Bitmap resize(Bitmap image, int maxWidth) {
    return Bitmap.createScaledBitmap(image, maxWidth, Math.round(image.getHeight() * (float) maxWidth / image.getWidth()), true);
}

A simpler example would be:

for(;;) {
    String foo = "hello";
    Console.print(foo + "world");
}

versus

for(;;) {
    Console.print("hello" + "world");
}

I believe the compiler optimizes things away anyway, so your test pair examples may perform similarly. In any case, inlining can make it easier to read the code. — Tim Biegeleisen, Dec 24 '15 at 00:11
For the examples you give there will be no difference in performance whatsoever. Don't even bother with "optimizations" like these, just do whatever reads best. — Louis Wasserman, Dec 24 '15 at 02:46
Second example optimization: `Console.print("hello world");` This saves a string concatenation (on each iteration), which is expensive. — Phantômaxx, Dec 24 '15 at 08:10

score 10 · Accepted Answer · edited May 23 '17 at 11:53

10

First: this is not what "inlining" means. See: What is inlining?

Second: no, there won't be any measurable difference in performance. In both of your code examples, it's likely that the compiled code will be identical for both versions.

edited May 23 '17 at 11:53

Community

1
1

answered Dec 24 '15 at 00:20

Mike Baranczak

8,291
8
47
71

2

The Java bytecode will be different, as the local variables are not eliminated (they're available for debugging). The JIT and presumably the Dalvik compiler would remove them. – chrylis -cautiouslyoptimistic- Dec 24 '15 at 01:39
After I posted this answer, I did a simple experiment, similar to LIProf. And the compiled files were indeed different. Except I used the `-g:none` flag, so there shouldn't have been any debugging symbols. So I guess it's a little more complicated than I thought. – Mike Baranczak Dec 24 '15 at 17:14

score 5 · Answer 2 · answered Dec 24 '15 at 00:51

I defined two simple classes Test1 and Test2 and compiled them.

public class Test1{
    public String f(){
        String s = "Hello";
        String t = "There";
        return s + t;
    }
}

and

public class Test2{
    public String f(){
        return "Hello" + "There";
    }   
}

Much to my surprise, the .class files are NOT of the same size.

-rw-r--r--  1 csckzp  staff  426 Dec 23 19:43 Test1.class
-rw-r--r--  1 csckzp  staff  268 Dec 23 19:43 Test2.class

Perhaps I shouldn't be surprised, since some amount of symbolic info is stored along with code. I ran the .class files through an online decompiler. Test1 was reconstructed pretty much the way it was typed in. Test2, on the other hand, decompiled this way:

public class Test2 {
    public String f() {
        return "HelloThere";
    }
}

The compiler's optimization clearly shows here. Perhaps there is a small penalty in Java for non-compact code.

I'm not surprised; the bytecode compiler does *very* minimal optimization. Their equivalence will be proven at runtime. — Veedrac, Dec 24 '15 at 07:10
The compiler tries to eliminate operations whose result can be determined at compile-time. That's why "Hello"+"There" got turned into "HelloThere". — Mike Baranczak, Dec 24 '15 at 17:11

score 3 · Answer 3 · answered Dec 24 '15 at 00:17

They're both the same. the former just makes things clearer than the latter.

There are situations such as the block below that make one-liners useful.

public boolean isEmpty() {
   return getCount() != 0;
}

If you want to make it easier to read, especially when it comes to equations, go for a variable. one-liners make it simple and short, but are good for short and simple logics.

This is my personal opinion.

meriton · Answer 4 · 2015-12-26T17:14:51.960

While local variables survive the translation to bytecode, they are very unlikely to survive just in time compilation. Moreover, even if the local variables were present, they would not significantly affect the performance of that method, as rescaling a bitmap is orders of magnitude more expensive than storing or retrieving a local variable.

Your second example about the string concatenation highlights a small exception to this rule, as the presence of local variables may inhibit compile time evaluation of the concatenation of constant strings. Again however, this is very unlikely to significant affect the runtime of your program, because you are probably not concatenating constant strings very often.

Generally speaking, the effect of inlining local variables on runtime performance is very rarely measurable, let alone significant. Therefore, your time is much better spent optimizing programmer performance by making your code easy to read and reason about.

Java - Will inlining code have benefits?

4 Answers4