Here is the piece of code I'm questioning about
for (int i = 0; i < this.options.size(); i++) {
RadioButton butt = this.options.get(i);
//do something with butt
}
would I gain a huge performance improvement if I changed it to:
RadioButton butt;
for (int i = 0; i < this.options.size(); i++) {
butt = this.options.get(i);
//do something with butt
}
EDIT: how about if this code is to be executed 30-50 times a second with options being around size 20?
For all realistic, measurable cases, there is absolutely no difference between the two performance wise. In fact, I'm pretty sure (admittedly I don't know for sure) they result in the exact same number of assignments and reference creations. It would be stupid for the JVM to create N number of reference holders. It would simply reuse the one created during the first iteration, simply giving it the reference in the next assignment. Which means only one reference holder is used for both cases (assuming this is true).
You're not creating objects here, you're just creating references, and whether you're creating one reference or more doesn't really matter.
Looking at the title, I knew this was going to be yet-another-misguided-performance-question.
A couple of things:
No, those are virtually identical except for the scope of the variable.
In general, if you're worried about micro-optimizations like that, you're spending your time on entirely the wrong thing. In this case it's moot since there is no difference, but even if you were talking about e.g. one assignment:
The difference is nanoseconds and completely negligible compared to other things you are doing.
The compiler is much smarter than you about optimizing.
The JVM interpreter and hotspot compiler are far smarter than you as well.
If you haven't set clear performance requirements, and you haven't determined that your code does not meet those requirements, and you haven't profiled your code and determined where the bottleneck is, you have no business asking optimization questions like this.
As for the GC comment you made in another answer: The GC happens in the background, is intelligent, and makes decisions that you have absolutely zero control over (aside from JVM command line tuning -- don't get excited, based on the fact that you asked this question, you probably aren't equipped to make good decisions about tuning parameters). Moving the reference from one place to another gives you no significant measure of control over how the GC handles it. Each time through the loop the previous reference is no longer reachable, the GC will clean it up at an undefined point in the future.
I think code and performance is almost same only looks different. You are not creating new instances but only copy references of objects from your collection.
But i like and usually use second approach.
The difference is not huge as assignment of the object is the biggest cost here. Also, the compiler will make your code more efficient, so in the end it is the same cost in performance.
In both cases you are creating the RadioButton object in the loop because RadioButton butt it's only a refernce and not an instance of the object. Presumably is this.option.get(i) which creates your object.
So my answer is: no.
The only thing that changes is that in the second loop you're creating this.options.size()-times the reference butt
Related
I would like to know if there's any difference of performance between these two ways of getting the parameter value in Java:
Option 1:
for(int i=0; i<1000; i++) {
System.out.println(object.getName());
}
Option 2:
String name = object.getName();
for(int i=0; i<1000; i++) {
System.out.println(name);
}
Maybe with just 1 attribute (name), the option 2 is better, but, what if I would have 50 different attributes? I would be wasting memory storing those variables.
Please, think big, in a huge system with tons of users accessing to the WebApp.
The first option should run object.getName() 1000 times, the other loop just once.
So, yes, obviously, there should be a certain performance impact. There is also a slight semantical difference: if that name isn't immutable, other threads might change it while that loop is running. Then option 2 might pick up that change at some random point in time, whereas option 1 will not do that.
Regarding the performance aspects: in Java, it is really hard to determine the effects of such subtle code changes. When that loop runs 100K times, the Just-in-time compiler would come in and translate everything into highly optimized machine code, using techniques such as method inlining, loop unrolling, constant folding, whatnot. It might even detect that object.getName() has no side effect, and thus turn your code into something that you put into your option 2 snippet. All of that happens at runtime, depending on the profiling information that the JVM collected for the JIT while running your code.
So, the typical answer regarding "java performance": avoid stupid mistakes (invoking a method that doesn't have side effects inside a loop would be such a mistake), but don't expect that someone could tell you "yeah, option 1 will run 500 ms faster". The "real" performance boosts in java are created by the JIT (and of course: clever designs for your implementation). Thus it is extremely hard to predict what this or that source code artefact will have at runtime.
And finally: please note that using System.out.println() is pretty expensive. So when your getName() really just fetches a property from memory, then the printing of that value to the console might be multiple times more expensive compared to fetching the values!
When I was learning C, I was taught to do stuff, say, if I wanted to loop through a something strlen(string) times, I should save that value in an 'auxiliary' variable, say count and put that in the for condition clause instead of the strlen, as I'd save the need of processing that many times.
Now, when I started learning Java, I noticed this is quite not the norm. I've seen lots of code and programmers doing just what I was told not to do in C.
What's the reason for this? Are they trading efficiency for 'readibility'? Or does the compiler manage to fix that?
E: This is NOT a duplicate to the linked question. I'm not simply asking about string length, mine is a more general question.
In the old times, every function call was expensive, compilers were dumb, usable profilers yet to come, and computers slow. This way C macros and other terrible things were born. Java is not that old.
Efficiency is important, but the impact of most program parts on efficiency is very small. But reading code still needs programmers time and this is much more costly than CPU. So we'd better optimize for readability most of the time and care about speed just in the most important places.
A local variable can make the code simpler, when it avoids repetitions of complicated expressions - this happens sometimes. It can make it faster, when it avoids expensive computation which the compiler can't do - this happens rather rarely. When neither condition is met, it's just a wasted line, so why bother?
Which is faster:
if(this.foo != 1234)
this.foo = 1234;
or
this.foo = 1234;
is the penalty of write high enough that one should check value before writing or is it faster to just write?
wouldn't having a branch cause possible mispredictions and screwup cpu pipleine? but what is the field is volatile, with writes having higher cost than reads?
yes, it is easy to say that in isolation these operations themselves are 'free' or benchmark it but that is not an answer.
There is a nice example illustrating this dilemma in the very recent talk by Sergey Kuksenko about hardware counters (slides 45-49), where the right answer for the same code depends on the data size! The idea is that "compare and set" approach cause more branch misses and loads, but less stores and L1 store misses. The difference is subtle, and I can't even rationalize why one factors overweight different on small data sizes, but become less signigicant on large data sizes.
So, measure, don't guess.
Both those operations are free: they really take almost no time!
Now if this code is in a loop, you should definitely favor the second option as it will minimize branch mispredictions.
Otherwise, what matters here is what makes the code the more readable. And again in my opinion, the second option is clearer.
Also as mentionned in the comments, assigning is an atomic operation which makes it thread safe. An other advantage for the second option.
They are not free. They cost time and space. And branching in a tight loop can actually be very costly because of branch prediction (kid's these days and their modern CPUs) . See Mysticial's answer.
But mostly it's pointless. Either just set to what it should be or throw when it's not what you expect.
Any code you make me read had better have a good reason to exist.
What I think you are trying to do is express what you expect it's value to be and assert that it should be that. Without context I can't tell you if you should throw when your expectations are violated or simply assign to assert what it should be. But making your expectations clear and enforcing them one way or another is certainly worth a few CPU cycles. I'd rather you were a little slower than quickly giving me garbage in and garbage out.
I believe this is actually a general question rather than java-related because of low level of this operations (CPU, not JVM level).
First of all, let's see what the choice is. On one hand we have reading from memory + comparison + (optionally) writing to memory, on other hand - writing to memory.
Memory access is much more expensive than registry operations (operations on data, already loaded to CPU). Therefore, choise is read + (sometimes) write vs write.
What is more expensive, read or write? Short answer - write. Long answer - write, but difference is probably small and depends on system caching strategy. It is not easy to explain in a few words, you can learn more about caching in the beautiful book "Operating Systems" by William Stallings.
I think in practice you can ignore distinction between read and write operations and just write without a test. That is because (returning back to Java) your object with all it's fields will be in cache for this moment.
Another thing to consider is branch prediction - others already mentioned that this is the reason to just write value without test too.
It depends on what you're really interested in.
If this is a plain old vanilla program, not only does the fetch/compare/branch of the first scheme take extra time, but it's extra code and complexity, and even if the first scheme did actually save a miniscule amount of time (instead of costing time) it wouldn't be worth doing it.
However, there are scenarios where it would be different. In an intensely multi-threaded environment with multiple processors modifying shared storage can be expensive, since changes to that storage need to be propagated to other processors. In such an environment it could be well worth it to spend a few extra instructions to avoid "dirtying" cache.
I wrote the following code in my application. ( office work )
#Override
public List<Outlet> getAllOutletForTouch() {
return outletDao.getOutlets();
}
This is the code one of my colleagues wrote.
#Override
public List<Outlet> getAllOutletsForMobile() {
List<Outlet> outletList = outletDao.getOutlets();
return outletList;
}
He created a new variable, assigned the values, and then returned the values; whereas I just returned the values directly calling the method. What is the convention for doing this?
As such there is no considerable performance difference in 2nd option as compare to the 1st, even on large scale, since as soon as the reference goes out of scope it will be GCed.
But it mostly about the coding style. IMO and as #Luiggi said in comments, 1st option is more readable but doesn't allow you to debug on return. If the return statement can throw exception that you might wanna debug, you need to go with 2nd option.
I would prefer first one in your case. You are unecessarily creating a new reference in 2nd case which goes to thread stack occupying some memory.
So i would go with first.
EDIT:
Elaborating my answer based on comments. An object is created on heap but all the references to that object go to Thread Stack.
So if multiple threads refer to same object then they will store their own reference in their stack.
EDIT:
Check the link Where is allocated variable reference, in stack or in the heap? for details of how references are stored
I think the first one (returning directly without creating variable) is better because we should always avoid creating variables if they are not useful.
There is not much performance hit but still make it a practice not to create useless variables.
Someone said that it will be GCed as soon as it goes out of scope but according to my understanding there is no fixed time when GC runs and you cannot force it to run. So it will stay in memory till the next time GC runs.
There's no performance penalty for #2. If it's executed frequent enough, VM will take care of optimizing it.
The #2 style is redundant and unnecessary, but no big deal.
Consider a simple following code in Java:
void func(String test)
{
if(str.length() > 0)
{
//do something
}
}
Does executing str.length() > 0 means that every time this function is called, 4 bytes of memory will be allocated to store 0 integer value ?
The memory needed to run this function (including the 0) would be part of the compiled program (.class / .jar/.apk), and has nothing to do with how many times the function is run. Even if the function is inlined, only the code size grows based on how many different locations the function is called, and there is NO memory allocation in run time, while the code runs.
Meanwhile 2 comments
There are far bigger issues with hardcoding.
I doubt length > 0 counts as hardcoding in any but the strictest sense.
If you write clean, clear and simple code the JIT will optimise the code best in 95+% of cases. If you attempt to out smart it, it is far more likely you will make the code worse, not better.
There are been some notable exceptions to this rule, but these tend to only last a few years. For example Locks in Java 5.0 were much faster than synchronized, however in Java 7 synchronized can be much faster.
When considering performance you should look at the behaviour of the whole system, not individual lines of code or even individual libraries. Failing to do this can mean you spend time worrying about something which makes no difference while a much more important thing is being ignored.
I have seen whole teams work on optimising a piece of a system for years when they could have made the whole thing faster just be changing a configuration setting. This is because they limited their view to the code they were writing, and didn't consider how they used the systems they connected to. Imagine wasting years of work when they could have seen more of a speed up with something trivial, and make sure this doesn't happen to you. ;)
No memory allocations are done when this code executes.
Its not looking anything serious in the above code as memory allocation point of view.
if(str.length() > 0) { }
Here its genuine requirement for comparision so it wont be consider as hard coding values.
If you are very strict towards memory utilization then always pick exact required data type.
This code is method local, hence after executing memory will reclaim automatically.
AS it is inside method.
Yes, but destroyed immediately after exiting the function. int is primitive type. Primitive types are considered the fastest in Java. So, I think it won't cost much.