I see in many pieces of code things like.

partial_calculation=sqrt(pow(abs(x-y))*pow(abs(x-y)));
complete_calculation1+=(partial_calculation*whatever)+something_else;
complete_calculation2+=(partial_calculation*whatever)+something_else;
complete_calculation3+=(partial_calculation*whatever)+something_else;
complete_calculation4+=(partial_calculation*whatever)+something_else;

I mean, code that makes some partial calculations and stores them in a variable and then reuses that variable to calculate some other results, when that partial calculation could have just been inlined in the next lines like so:

complete_calculation1+=(sqrt(pow(abs(x-y))*pow(abs(x-y))))*whatever)+something_else;
complete_calculation2+=(sqrt(pow(abs(x-y))*pow(abs(x-y))))*whatever)+something_else;
complete_calculation3+=(sqrt(pow(abs(x-y))*pow(abs(x-y))))*whatever)+something_else;
complete_calculation4+=(sqrt(pow(abs(x-y))*pow(abs(x-y))))*whatever)+something_else;

So i've been wondering, is this done just for clarity, or is there some benifit to the performance, because when i think of it, it kind of seems like "sqrt(pow(abs(x-y))*pow(abs(x-y)))" is going to be cached and there is no need to store it in another variable in the first place.

You can assume the compiler's smart enough to do that for you, or you can take the safe path and store the extra varaible yourself. If the compiler doesn't do it, the second method is bound to be slower.

Yeah, since it's so easy to do (and gives you cleaner code), you might as well. In the best case, you've made an optimization, at the worst case, you've got cleaner code that performs exactly the same.

No real downside, is there? [wink]

It also makes it a lot easier for you if you have to change that formula later on. (Nothing worse than having to search and replace 30 instances of it... Except when you replace 29 and forget one, and get weird bugs because of it)

So much easier (and safer, and potentially faster) to just store the first calculation in a variable you can use afterwards.

Do it for clarity, because if you are in the habit of trying to 'inline' everything, you are bound to screw up sooner or later (e.g. by not accounting for re-negating a negative properly, or by trying to "simplify" a huge expression manually and messing it up). Also because short code* just looks better :)

* short in the sense of number of things that "appear to be done"; don't go using all one-letter variable names on me now.

Whether it's more optimized or not you should store the result and reuse it anyway. Don't embrace code redundancy! Let's weigh the benefits of each:

The one with the partial calculation makes the complex calculation only appear once in code to the person looking at it. One simple identifier is used in the following expressions making it easy to see that it's the same value used. Both a programmer and a compiler can much more easily see that you only need to do those calculations and call that function only once, using the return for all of the remaining calculations. You can give that intermediate calculation a name that identifies what it represents in the following expressions, making it more clear as to what you are doing. You have one more line of written code, but you have much less operations. If you wish to change how the calculation is performed, you only have to change it once for the entire group of statements as opposed to once for each line. Finally, it's possible that the code will be more optimized, since in order to make that optimization the compiler would have to know that the functions you are calling produce the same result every time for the same values.

Now, what exactly do you think you benefit from showing the redundant calculation in code? Sure, you have one less line of code, but you have a lot more operations; most of which are redundant. It is less obvious to a reader or a compiler that the calculation has the same result in each expression. The expression is harder to read. It's possibly less optimized, and finally, it's harder to maintain.

Go with storing the partial calculation.