Three questions about doing lots of calculations

Question

This is just a series of questions regarding doing lots of computations. Either I couldn't find the answers online or I still need clarification.

1. Is it faster to pass (float, float, float) as method parameters vs (float[]) where the array has three terms?

2. Is it faster for a method to return a float[] vs setting the contents of a float[] that is passed to the method as an argument?

3. Is it faster to replace method calls with the actual calculations i.e. instead of is A=sum(B,C) any slower than A=B+C? assuming sum(x,y){return x+y}

EDIT:

Thanks for all the answers, guys! Before I close this thread I have one more quick question if anyone knows:

4. If I'm using a class to repeatedly calculate the same statistics over and over again (and then throwing them away), would it be any better to create instance variables to act as containers to avoid continuous re- and de-allocation?

Answer 1

Is it faster to pass (float, float, float) as method parameters vs (float[]) where the array has three terms?

That depends. If you already have the array of floats handy, it shouldn't make any difference whatsoever. If you are constructing the array every time, that would take some time for the assignments to the array, and possibly some time for the construction of the array.

Does it matter? If you do it in a tight loop that is executed a few million times in succession, and that many times during the life of your application, it may certainly do.

Is it faster for a method to return a float[] vs setting the contents of a float[] that is passed to the method as an argument?

If you need to construct the array of float every time for your return value, than that is certainly not going to be faster than setting values in a pre-existing array. Simply because both options involve setting values, and one of them has the extra task of creating a new array. But creating a new array may be really, really fast.

Still, if you do it many millions of times in your app in quick succession, benchmark it, it may save you some time.

Is it faster to replace method calls with the actual calculations i.e. instead of is A=sum(B,C) any slower than A=B+C? assuming sum(x,y){return x+y}

Almost impossible to say. The builtin HotSpot code optimizer is pretty good at discovering such things and optimizing that for your.

If you benchmark this, try making the sum method private, which will make it easier for HotSpot to decide that it can be inlined (although it will also discover this by itself, if you don't have any overridden implementations of the sum method)

---

The one thing about benchmarking here is:

It may help your application right now, with the current version of the VM that you are using (and your current codebase). If you decide to upgrade to a new version of the VM, you may discover that the performance characteristics change, and you may need to optimize again.

So only do it if it really matters to your application, otherwise it may be wasted effort.

Better to focus on your algorithm and its space and time complexities first; any gains there are gains forever.

Answer 2

1) Is it faster to pass (float, float, float) as method parameters vs (float[]) where the array has three terms?

1.) Depends. If the separate floats aren't contiguous in memory then a float[] could help.

2) Is it faster for a method to return a float[] vs setting the contents of a float[] that is passed to the method as an argument?

2.) Depends on if the float[] already exists in either case. If you're creating a new float[] and passing it in, or creating a new float[] and returning it, the cost is the same. But if in either case you can use an existing float[] somehow, that will be faster and create less allocations.

3) Is it faster to replace method calls with the actual calculations i.e. instead of is A=sum(B,C) any slower than A=B+C? assuming sum(x,y){return x+y}

3.) I'm not sure, I'm more of a C# programmer. I know that on basic CLR (common language runtime) like used by the Xbox 360 when running C#, manual calculations were far cheaper than using overloaded methods. I'm not sure if Java has similar issues on any platform.