If "flag" is true I have to perform step no. 1 otherwise skip it. Is there a way out to skip this unnecessary repetitive check within the loop. (As the value of flag is not changing while the execution of the loop)
private void method(boolean flag) {
while (man > woman) {
if (flag) {
// Step no. 1
System.out.println(flag);
}
}
}
I'm not sure it is productive to worry about optimizations at this level. Generally it is more important to get the program working and move on to the next problem.
Having said that, there is an optimization called loop unswitching that some compilers will do for you. They duplicate the loop, once with and once without the conditional, and move the conditional outward to select the loop. (In your example you could make the entire loop conditional but I presume that's just an artifact of simplification for Stack Overflow.)
But this is just one more reason not to worry too much about optimizations, at least, not until you have a profile and you know that this region of code is responsible for detectable amounts of runtime.
Still, it's best to write code as cleanly as you can and puzzling through issues like this will teach you good things...
In fact, loop-invariant conditionals bother me too. I don't believe there is a general answer. There are fancy answers involving higher order functions or lambdas, "leave-it-to-the-compiler" answers, refactor-the-whole-outer-routine answers ... I would generally approve of whatever makes the code appear smaller. You have to prioritize in order to discriminate...
It depends on the scope of do. If do is always true, you don't need to check for it and you can remove if (do). There is no reason to set a variable to true if it will always be true. What is the scope?
If the value of do changes at any time in the loop, you have to check for it every time unless you rewrite the code so that the do == true state is handled outside the current loop (perhaps in a smaller loop; it depends on what you're trying to do [no pun intended]).
while (man > woman) {
Beware of infinite loops here :-)
Related
In a program where I have, say, 50 for loops that run every so often; there are 50 ints being created every time they are run and then consuming memory for each of them.If I declare an int i at the beginning of every class and then reuse it in each for loop, there would now be, say, 5 ints i (i = number of classes) created and then reassigned a value of 0 in each loop, saving space by not flooding the heap with is.Would that help the program's performance or it just wouldn't be too much of a difference? Does heap memory works as I think it works in this case?
Reusing simple, small, short living ints for multiple loops is a code smell - don't do it.
If your loops are in the same method, many loops might be a code smell on it's own. Probably you should split the method into smaller chunks of code which can be more easily tested, independent from each other.
Counters in loops are almost always independent from each other. An exception might be a loop which counts up and the next one is counting down, where the initial value is depending on the last value of the former loop. If you reinitialize your counter as the very first statement of a for loop, which is the case for 99% of the loops I have seen so far, they are independent from each other and the declaration of the counter variable should reflect that. It's an important kind of documenting your code.
Reusing a counter only documents that there are some coders with wrong ideas of optimization.
Now the worser idea is to define some counters on class level (some, because you have nested loops) and call the same counter from different methods. Wow! You woulnd't consider that, would you? That would not only avoid making the class thread save - you couldn't call one method from another one without shooting yourself into both feet.
Think of the case where you have a method with a for loop, which you are going to refactor for some reason. Maybe a more elegant solution is possible with Java9, but it has a for-loop with some i, and the i is initialized at the top of the for loop for (i=0; ... and now you look where it is coming from, and realize, it is not declared in that method, but an instance variable! And the class is 500 lines long with, let's say 20 methods, each on average 25 lines long. Many of them using that same i. Now you have to investigate, which method is called by your method, which method calls your method and might depend on the value of i which you end with, which can be run in parallel. You're doomed! Instead of 25 lines of code, you have to have 500 lines of code in your head, to reason about, what is going on.
The scope of local variables should be as narrow as possible, as long as there is no good reason to reuse it. The less lines a variable is in scope, the easier it is to understand some code.
You have always to look where a variable is initialized to find it's current value, where it is declared, to find it's type (is it a long, an int, a byte, a short?), where it is reused later. Counters are almost never reused. Make it easy to reason about your code by declaring them just in the for loops head, so everybody knows, it has no influence on later code.
Well, and use the simplified for loop where it makes sense, to prevent the ugly off-by-one errors. Then you don't have to reason about a few bytes being used.
But in the end, I admit, for a beginner, it is a reasonable question to come up with. I had the idea in former times, too. :)
I don't see why you'd need to have that many loops in your main method. If those integers are only being used as iterators and you really have that many loops in your program you should probably arrange them into specific functions/methods to perform whatever tasks these loops are doing.
By doing so you'd have local variables being used as iterators for each one of those methods and the memory used up for these variables would be freed up when the method finishes it's execution.
No it doesn't matter really as compilers these days are very powerful and the difference is negligible, but the main issue here is do you really need to set 'i' value on top, as your code grows and you start using 'i' in different/complex scenarios you might start seeing 'i' behaving differently and will have no clue why its happening and its pain to debug the whole thing to find what caused the issue
If you really want to know the difference you can refer to this link which talks about almost the same scenario your talking about Difference between declaring variables before or in loop?
So lately I've been trying to figure out how 'heavy' some statements are.
For example is it a good thing to check for every possible exception with if statements or will that slow down the programm considerably? So I bassically want to know how 'heavy' the folling statements get when used a lot. This is mostly just a question out of curiosity because today's computer are so fast that it probably doesn't matter But it will also help me choose between different ways of doing things though perfomance improvements might only be minimal.
A simple while loop how 'heavy' is the loop itself not the code inside it?
while(true){}
A for loop probably smiliar to the while loop?
for(int i = 0; true; i++){}
A do while loop probably smiliar to the above two too?
do{...}while(true)
An if statement how 'heavy' does this get?
if(true){}
A switch statement
switch(0){
case 0:
}
And is a switch statement less 'heavy' or 'heavier' than else if statements
And the instanceof check how 'heavy' is it?
if(obj instanceof Player){}
An is null check I heard that this one is really 'light' is that true?
if(obj == null){}
And a constructor call
new Object();
And a method call
MyClass.doSomething();
A variable assignment
int i = 10;
I tried searching on the internet but I didn't find a web page that was comparing them all to each other or something smiliar. But if some of you have a good documentation on this I would be more than happy to read it.
The answer to pretty much everything there is "It depends". It depends on the JITC, what's inside those calls, surrounding code, how hot the code is, how good your branch predictor is, etc. But if you're worried about the performance of control flow structures, you're almost certainly looking in the wrong place...
Disclaimer: This analysis goes right out the window if you actually put something in the loops and/or evaluate a "real" condition, because evaluating those would dwarf the cost of the control flow structures themselves. But I'll just take everything literally now, because otherwise I can't give a solid answer.
while(true){}
This would probably be optimized to an unconditional branch by the JITC. So not "heavy" at all.
for(int i = 0; true; i++){}
Again, JITC optimizations could probably turn this into an unconditional branch + increment. "heavier" than while(true), but that's because of the increment more than anything. Probably could be optimized further by the JITC; in this case, it's possible that the increment would be skipped entirely.
do{...} while(true);
Same as while(true). Probably optimized to unconditional branch by JITC.
if(true){}
If this isn't eliminated in bytecode compilation (and it might not be; I think I remember some special rules concerning how control flow is evaluated for if statements), then it'll probably be optimized by the JITC to a no-op and essentially be eliminated from the program.
switch(0){
case 0:
}
Not sure about this case specifically, but I wouldn't be surprised if the JITC optimized this away entirely. Otherwise, a switch could be a jump table or a binary-search-ish instruction, depending on how sparse the cases are.
And is a switch statement less 'heavy' or 'heavier' than else if statements
This depends entirely on 1) whether you can use one instead of the other, and 2) what you are comparing. So can't say anything about this.
if(obj instanceof Player){}
if(obj == null){}
These two particular snippets would probably be removed by the JITC, otherwise I would expect that instanceof and == null would be reasonably fast, as I think there are bytecode instructions that I would expect would be reasonably optimized. I'm not exactly sure whether to call these "heavy" or "light", because there isn't a point of comparison...
new Object();
I hear object creation these days is cheap. So I'll go with "light", if you're talking about the actual allocation. The performance of the entire statement, though, depends on what's going on in the constructor.
MyClass.doSomething();
Depends on whether the method has been inlined. If so, the it's as cheap as it gets. If not, then it's the cost of a vtable lookup, which may or may not be expensive. Not sure.
int i = 10;
Assigning a value/reference probably isn't expensive at all, since that's a decent amount of a program...
Quick question? Is this line atomic in C++ and Java?
class foo {
bool test() {
// Is this line atomic?
return a==1 ? 1 : 0;
}
int a;
}
If there are multiple thread accessing that line, we could end up with doing the check
a==1 first, then a is updated, then return, right?
Added: I didn't complete the class and of course, there are other parts which update a...
No, for both C++ and Java.
In Java, you need to make your method synchronized and protect other uses of a in the same way. Make sure you're synchronizing on the same object in all cases.
In C++, you need to use std::mutex to protect a, probably using std::lock_guard to make sure you properly unlock the mutex at the end of your function.
return a==1 ? 1 : 0;
is a simple way of writing
if(a == 1)
return 1;
else
return 0;
I don't see any code for updating a. But I think you could figure it out.
Regardless of whether there is a write, reading the value of a non-atomic type in C++ is not an atomic operation. If there are no writes then you might not care whether it's atomic; if some other thread might be modifying the value then you certainly do care.
The correct way of putting it is simply: No! (both for Java and C++)
A less correct, but more practical answer is: Technically this is not atomic, but on most mainstream architectures, it is at least for C++.
Nothing is being modified in the code you posted, the variable is only tested. The code will thus usually result in a single TEST (or similar) instruction accessing that memory location, and that is, incidentially, atomic. The instruction will read a cache line, and there will be one well-defined value in the respective loaction, whatever it may be.
However, this is incidential/accidential, not something you can rely on.
It will usually even work -- again, incidentially/accidentially -- when a single other thread writes to the value. For this, the CPU fetches a cache line, overwrites the location for the respective address within the cache line, and writes back the entire cache line to RAM. When you test the variable, you fetch a cache line which contains either the old or the new value (nothing in between). No happens-before guarantees of any kind, but you can still consider this "atomic".
It is much more complicated when several threads modify that variable concurrently (not part of the question). For this to work properly, you need to use something from C++11 <atomic>, or use an atomic intrinsic, or something similar. Otherwise it is very much unclear what happens, and what the result of an operation may be -- one thread might read the value, increment it and write it back, but another one might read the original value before the modified value is written back.
This is more or less guaranteed to end badly, on all current platforms.
No, it is not atomic (in general) although it can be in some architectures (in C++, for example, in intel if the integer is aligned which it will be unless you force it not to be).
Consider these three threads:
// thread one: // thread two: //thread three
while (true) while (true) while (a) ;
a = 0xFFFF0000; a = 0x0000FFFF;
If the write to a is not atomic (for example, intel if a is unaligned, and for the sake of discussion with 16bits in each one of two consecutive cache lines). Now while it seems that the third thread cannot ever come out of the loop (the two possible values of a are both non-zero), the fact is that the assignments are not atomic, thread two could update the higher 16bits to be 0, and thread three could read the lower 16bits to be 0 before thread two gets the time to complete the update, and come out of the loop.
The whole conditional is irrelevant to the question, since the returned value is local to the thread.
No, it still a test followed by a set and then a return.
Yes, multithreadedness will be a problem.
It's just syntactic sugar.
Your question can be rephrased as: is statement:
a == 1
atomic or not? No it is not atomic, you should use std::atomic for a or check that condition under lock of some sort. If whole ternary operator atomic or not does not matter in this context as it does not change anything. If you mean in your question if in this code:
bool flag = somefoo.test();
flag to be consistent to a == 1, it would definitely not, and it irrelevant if whole ternary operator in your question is atomic.
There a lot of good answers here, but none of them mention the need in Java to mark a as volatile.
This is especially important if no other synchronization method is employed, but other threads could updating a. Otherwise, you could be reading an old value of a.
Consider the following code:
bool done = false;
void Thread1() {
while (!done) {
do_something_useful_in_a_loop_1();
}
do_thread1_cleanup();
}
void Thread2() {
do_something_useful_2();
done = true;
do_thread2_cleanup();
}
The synchronization between these two threads is done using a boolean variable done. This is a wrong way to synchronize two threads.
On x86, the biggest issue is the compile-time optimizations.
Part of the code of do_something_useful_2() can be moved below "done = true" by the compiler.
Part of the code of do_thread2_cleanup() can be moved above "done = true" by the compiler.
If do_something_useful_in_a_loop_1() doesn't modify "done", the compiler may re-write Thread1 in the following way:
if (!done) {
while(true) {
do_something_useful_in_a_loop_1();
}
}
do_thread1_cleanup();
so Thread1 will never exit.
On architectures other than x86, the cache effects or out-of-order instruction execution may lead to other subtle problems.
Most race detector will detect such race.
Also, most dynamic race detectors will report data races on the memory accesses that were intended to be synchronized with this bool
(i.e. between do_something_useful_2() and do_thread1_cleanup())
To fix such race you need to use compiler and/or memory barriers (if you are not an expert -- simply use locks).
I recently rediscovered the use of breaking back to a label. Now I'm wondering if it is possible to break back to a label from another class.
Example of what i want:
Main.class
label:
for (Product p : ProductList) {
if (p.getSet() == true) {
classHandler();
}
}
Classhandler.class
someFunction() {
break label;
}
While I was typing this I actually tried making a local function in my Main class (so I could just call that function instead) but even there I got the undefined label: label error.
No, you can't. And you shouldn't.
If the condition for breaking is some problem, then throwing an exception would be the correct approach.
Otherwise you should do something like returning a flag that indicates if other products should still be handled and reacting on that in your loop.
As you noticed you can't even break through method-borders, and that's a good thing. break and continue are powerful tools, but can easily make your code confusing, if used in the wrong way. For example a break hidden inside a huge code block can be easy to miss, but if you use a continue at the very top of a method to skip an iteration based on some condition, then the intention is pretty clear.
The label that you break to must be in scope. From the java sun documentation:
A break statement with label Identifier attempts to transfer control
to the enclosing labeled statement (§14.7) that has the same
Identifier as its label; this statement, which is called the break
target, then immediately completes normally. In this case, the break
target need not be a while, do, for, or switch statement. A break
statement must refer to a label within the immediately enclosing
method or initializer block. There are no non-local jumps
No, you cannot. That does not even work between two methods of the same class. Labels are scoped (at the most) within a single method.
It doesn't make sense, since there is no guarantee that label exists, not even that someFunction() is called within a loop.
I just read this thread Critical loop containing many "if" whose output is constant : How to save on condition tests?
and this one Constant embedded for loop condition optimization in C++ with gcc which are exactly what I would like to do in Java.
I have some if conditions called many times, the conditions are composed of attributes define at initialization and which won't change.
Will the Javac optimize the bytecode by removing the unused branches of the conditions avoiding to spend time testing them?
Do I have to define the attributes as final or is it useless?
Thanks for you help,
Aurélien
Java compile time optimization is pretty lacking. If you can use a switch statement it can probably do some trivial optimizations. If the number of attributes is very large then a HashMap is going to be your best bet.
I'll close by saying that this sort of thing is very very rarely a bottleneck and trying to prematurely optimize it is counterproductive. If your code is, in fact, called a lot then the JIT optimizer will do its best to make your code run faster. Just say what you want to happen and only worry about the "how" when you find that's actually worth the time to optimize it.
In OO languages, the solution is to use delegation or the command pattern instead of if/else forests.
So your attributes need to implement a common interface like IAttribute which has a method run() (or make all attributes implement Runnable).
Now you can simply call the method without any decisions in the loop:
for(....) {
attr.run();
}
It's a bit more complex if you can't add methods to your attributes. My solution in this case is using enums and an EnumMap which contains the runnables. Access to an EnumMap is almost like an array access (i.e. O(1)).
for(....) {
map.get(attr).run();
}
I don't know about Java specifics regarding this, but you might want to look into a technique called Memoization which would allow you to look up results for a function in a table instead of calling the function. Effectively, memoization makes your program "remember" results of a function for a given input.
Try replacing the if with runtime polymorphism. No, that's not as strange as you think.
If, for example you have this:
for (int i=0; i < BIG_NUMBER; i++) {
if (calculateSomeCondition()) {
frobnicate(someValue);
} else {
defrobnicate(someValue);
}
}
then replace it with this (Function taken from Guava, but can be replaced with any other fitting interface):
Function<X> f;
if (calculateSomeCondition()) {
f = new Frobnicator();
else {
f = new Defrobnicator();
}
for int (i=0; i < BIG_NUMBER; i++) {
f.apply(someValue);
}
Method calls are pretty highly optimized on most modern JVMs even (or especially) if there are only a few possible call targets.