ArrayCopy Vs for loop

[Walsh graham]

Hi Hi,

the text below is from the following link;

http://java.sun.com/developer/technicalArticles/Programming/Performance/

"Native methods are really fast.
This sounds silly, but I had heard that the overhead of invoking a native method was so high that it might be the case that small Java methods would be faster. Not! In my test case, I implemented System.arraycopy in plain Java. I then compared this using arrays of different sizes against System.arraycopy . The native (original) method was about an order of magnitude faster, depending on the array size. The native-method overhead may be high, but they're still fast compared to interpreting byte code. If you can use native methods in the JDK, then you can remain 100% pure and have a faster implementation than if you used interpreted methods to accomplish the same thing. "


Ive tested this using some very basic java code, I have only used code like this to do timing;

long startTime = java.lang.System.currentTimeMillis();

so its not real CPU time (I'm on jdk 1.4 and so I don't have access to the new ThreadMXBean interface and features provided for measuring CPU time.


Anyways, I'm seeing that within the debugger there are significant differences (arrayCopy is about 15 times faster). Its under debugger control so this timing doesn't really count. I was encouraged however and went straight to the command line to test outside the debugger.

At the command line, the results show no differences. They both take more or less the same time.

So my questions are;

1) If I measure using real CPU time, can I expect to see greater performance with the System.ArrayCopy approach?
2) I'm compiling under eclipse and I'm not sure if debug versus non-debug mode differences are in place. I can't see where in eclipse I should specify "-g:non" when compiling. I understand eclipse uses its own internal javac compiler. Thus, I'd like to know how to specify a non-debug build (if that makes sense).

thanks for any input.

G

Outside

[Kees Jan Koster]

Dear Graham,

You will probably gain more overall performance by moving to Java 1.6 than you could ever win in this kind of optimisation.

[Walsh graham]

thanks for the reply. I could google it but if you know any good articles that outline the why and how about these 1.6 improvements, I'll definitely check them out.

thanks and have a nice day

Graham

[Kees Jan Koster]

Dear Graham,

Performance all depends on the problem you are trying to solve. I deal with application servers all day, so my problem area is getting threads onto processors to do some actual work. So I am interested in things like http://java-monitor.com/forum/showthread.php?t=133

What problem are you trying to solve? Actual problem, not synthetic ones. :-)

[Walsh graham]

Hi Hi,

thanks for the reply. There's no real problem at all, I'm just toying with theory and curious to hear peoples opinions on ArrayCopy vs looping. All is actually good for a change!

have a nice day.

G

[Joe Ess]

That article was written 12 years ago. There's been some big changes in the Java world in those years.
1. Use buffered I/O. = can't argue with that.
2. Try to avoid new. = not as big a deal as it used to be
3. Native methods are really fast. = This should probably be "native methods that are built into the JVM are really fast" because that's what he's testing. My personal rule of thumb is: "if there's a JVM method to do something, use it, because it's less code for me to maintain and it's probably faster". As Kees Jan Koster states, worrying about small optimizations like this at the expense of solving the problem at hand is counterproductive.
4. String operations are fast. = The author points out that "String operations can hide a lot of new operations." without an example. This article explains how string concatenation can create lots of extra objects.
5. InetAddress.getHostAddress() = If one needs the host address, what's the alternative?
6. java.util.Date = has long since been deprecated in favor of Calendar
7. Avoid java.lang.String.hashCode() = If one looks at the code of java.lang.String, it calculates the hash code once and stores it, so this is no longer an issue.
8. Architecture matters. = This will always be true.
9. I have mixed feelings about java.util.Hashtable = Two things: HashMap is available and is not synchronized, and synchronization isn't the problem it used to be.
10. String.getBytes() takes about ten times as long as String.getBytes(int srcBegin, int srcEnd, byte dst[], int dstBegin) = never looked at either of these methods. My opinion is that if one is working with bytes a lot, one probably should use C and not Java.
11. Synchronized method invocation is about six times longer than non-synchronized invocation. = As I linked above, not true any more.
12. Be careful about using lots of debugging code. = True, one should use either the Java java.util.logging package or Log4J to mange debugging on-the-fly, and one should always be cognizant when building Strings, especially if they may not be used (see my link in #4)
13. Profiles of the Java Web Server show it spending about 1-2% of its time running the garbage collector under most uses. So we rarely worry about performance of the garbage collector. The one thing you want to be careful about is response time. = I'd agree with that. Concentrate on what really matters (i.e. getting the task done, not micromanaging Objects).

[Kees Jan Koster]

Dear Graham,

If all you are doing is toying, why not check out the Java 7 sources and write your own, faster version of the array copy? You'd be a hero and learn something. :-)

[Walsh graham]

you know, I might just do that

[Kees Jan Koster]

Dear Graham,

I found the Java run-time library source code very readable. The older code (since 1.0) tends to be more C-like in style, telling the background of the programmers who worked on the JDK back then. The newer code is nice and clean and (imagine that) well documented. The JVM itself is a different matter, since it has to deal with the gritty, processor dependent details.