... performance

Performance Tuning
#1

What is the performance of methods using … parameters as opposed to methods using a single element or an array as parameters? In other words, how does code A compare to code B, performance-wise.

Code A:

public void add(final E... aObjectToAdd) {
   //code here
} //end add

Code B:

public void add(final E object) {
   //code here
} //end add

public void addAll(final E[] aObjectToAdd) {
   //code here
} //end addAll

It is my assumption that the … method creates an array for the method even if you give it only one argument. If such is the case, then I would assume that the … method will always perform the same as the array method and worse than the single object method.

I’ve been using the … because it’s easier. However, I might not want to use it in the utility classes I’m writing if it harms performance.

If I define the following 2 methods:

public void add(final E object) {
   //code here
} //end add

public void add(final E... aObjectToAdd) {
   //code here
} //end add

Will it use the single object method for single objects and the other method for lists of objects? If such is the case, I will probably do it that way.

#2

Yes, unfourtunatly the varargs create an Object[] for now - maybe future runtime optimizations can decrease the cost of this operation.
If you write something very sensitive to performance like a raytracer where a vararg-method is called millions of times, I would suggest not using it.

lg Clemens

#3

I think I will just have add(Object) and addAll(Object…). Since I’m using different method names, there’s no possible conflict.

I’m writing generic utility classes, so I would like them to be as efficient as possible. The add(Object) method isn’t really necessary for completeness, but it would be faster than addAll(Object…) when only adding one Object. The array creation might only be 10 or so instructions, but however many instructions it takes, it’s unnecessary.

It’s faster to use addAll(Object…) if you want to add multiple Objects because the utility class needs to reallocate an array when it runs out of space. So I’ll include both methods.

#4

As far as I know the varargs is internally changed into an Array. When speaking about a perfomance issue, keep 2 things in mind:

  • The method has to be called often in order to generate an issue on perfomance just because of the array parameter.
  • The method has to be called a lot of times with only one parameter, where the simple version would be better.

Especially the second point brings me to:
If you have a method with varargs, it should usually be called with multiple arguments. If it is called like 90% with one argument and 10% with more than one, it could be strange programming.

Generally I would say this is another case for: Code first, optimize later. You can think a lot about the performance of the varargs method, but probably when you use it you will never measure a performance bottleneck caused by varargs. So I would suggest only to care about it, if you actually have a performance issure with varargs on your hand, otherwise feel free to use it.

-JAW

#5

I’ve already written the code.

My program runs fine, so it’s no big deal. However, this is reusable code that I plan to eventually give out for free. I want it to be fast.

Seriously, writing another method that doesn’t use … takes little time and isn’t particularly bug prone. Optimizing this is relatively safe. This isn’t one of those cases where the optimization broke my program or took a really long time to implement.

Is it really worth profiling and so forth when I know the result will be an improvement (albeit a marginal one), and it’s so easy to do?

The truth is that I only add one item to an array in about 70% of my code, but the add-one occurrences are far more likely to happen inside a loop. Adding multiple items at once mostly occurs during initialization.

Enough of my code adds multiple items at once that I want the … method, but I want to usually use the regular method.

#6

If you have single-threaded code, you can do this: (to get rid of the array-construction)


private static Object[] arr = new Object[1];
public void doSomething(Object obj)
{
   arr[0] = obj;
   this.doSomething(arr);
}

public void doSomething(Object... objs)
{
    // lots of stuff
}
#7

I don’t have single-threaded code. Now that everyone’s getting multi-core processors, what would be the point?

Since the methods I was implementing are extremely simple, I might as well just have it implemented twice, once for an individual object and once for an array.

#8

Will you be performing get operations upon this ‘collection’ (much?) more frequently than add?

If so, the unavoidable type casting necessary during retrieval will probably be a greater performance hinderance.

I’d forget performance, and make sure you write it ‘properly’ taking advantage of whatever language features you feel increase the quality of your code.

#9

Though it’s not clear from my posts to this thread, I did use generics. There is no type casting.

In general, get operations will be performed more than add operations, but that’s not always the case. In fact, there was one case where get was enough more frequent than add that I started coding a CopyOnWriteArray, but the situation changed before I ever used the CopyOnWriteArrayCode.

I’m primarily concerned about performance in reusable library code. I want it to run quickly because it will be reused in so many places.

The issue with … is more than just creating the array. It’s also that I have to have a for loop for using the array. Having two methods saves me alot of extra processor cycles because the class is used everywhere in my code. It doesn’t seem to reduce the readability of my code noticeably.

#10

If you have a good reason to add such a method for performance reasons (i.e. the method is typically called in performance critical code like inner loops), than I’d just go for it. It’s not like your suggestion immediately makes the lib messy.

Generally I’m all for ‘design clean code first, optimize later’, but there are cases where it makes perfect sense to think about performance in advance too. It’d be such a waste having to refactor loads of code, just because the library method you use inherently doesn’t perform well enough and the library method you would need to fix that wasn’t there yet.

But then again, just test it first to see if it’s at all likely (or even possible) to become a performance bottleneck.

[quote]Though it’s not clear from my posts to this thread, I did use generics. There is no type casting.
[/quote]
If you use generics, there is type casting. The compiler just hides it away from you.

#11

It’s not something that’s going to make a big difference. It mostly has an effect during the program’s initialization, where add methods are called in some inner loops.

If it weren’t for the … parameters, I would have separate add and addAll methods anyways. It just seems strange to create an array and then execute a for-loop (within the method) to add one element.

I wasn’t aware that generics did type casting internally, but I vastly prefer using generics anyways. Either way, it was my understanding that neither generics nor type casting have any effect upon the bytecode, though I could be wrong about this.

Even if generics are slower, I would still use them because they produce compiler errors and/or warnings when I make the sorts of mistakes I often make.

#12

[quote]If it weren’t for the … parameters, I would have separate add and addAll methods anyways. It just seems strange to create an array and then execute a for-loop (within the method) to add one element.
[/quote]
Yes, I know what you’re saying. I personally don’t like this kind of syntactic magic like ‘…’ much (except maybe for some corner cases), so I would probably use add/addAll in the end. Even if the compiler would be smart enough to optimize this to something similar like your add/addAll.

[quote]I wasn’t aware that generics did type casting internally, but I vastly prefer using generics anyways. Either way, it was my understanding that neither generics nor type casting have any effect upon the bytecode, though I could be wrong about this.
[/quote]
It’s my understanding that the compiler inserts type casts where needed.

[quote]Even if generics are slower, I would still use them because they produce compiler errors and/or warnings when I make the sorts of mistakes I often make.
[/quote]
Absolutely.
And I don’t think generics are slower at all, it’s just nicer syntax and better compile time checking.