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");
}
Basically, inlining is a way to optimize compiled source code at runtime by replacing the invocations of the most often executed methods with its bodies. Although there's compilation involved, it's not performed by the traditional javac compiler, but by the JVM itself.
Inlining is the process of replacing a subroutine or function call at the call site with the body of the subroutine or function being called. This eliminates call-linkage overhead and can expose significant optimization opportunities.
inline functions might make it faster: As shown above, procedural integration might remove a bunch of unnecessary instructions, which might make things run faster. inline functions might make it slower: Too much inlining might cause code bloat, which might cause “thrashing” on demand-paged virtual-memory systems.
In this article The debugger also displays inline functions in the call stack. For inline functions, the debugger displays local variables, but not parameters. When code gets optimized, it is transformed to run faster and use less memory.
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.
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.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With