Mailing Lists: Apple Mailing Lists
Image of Mac OS face in stamp
 
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Array.Length() overhead

Michael Nischt wrote:

On Dec 1, 2006, at 2:49 AM, email@hidden wrote:

> Is there enough overhead (primarily referring to time) with finding
> the length of an array, such that in a long loop you would want to
> read the length once and store it in a variable for future reads
> rather than reading the length from the array itself over and over
> again?
>
> I'm just asking because this is true in some other languages, and
> I'm new to Java.

I'm not a pro in this area, but AFAIK bounds checks are eliminated by
hotspot in the followign case

for(int i=0; i<array.length; i++){
        ..
}

There is no such thing in Java as Array.Length(). The parenthesis imply a method call, but class Array does not have a method named "Length" (or "length" with the correct case for a method name, although array types do have a field named "length" as others have noted). It does have a method "getLength" (that takes a single Object as a parameter), which is presumably what you really meant. This is distinct from using the field named "length" that is present in all Java arrays (both arrays of Objects and arrays of primitive types). Use of the field should perform very much like accessing a field (which is the abstraction that Java presents, but it may not actually be implemented that way). This is very commonly done, so the JVM and JITC should be tuned to optimize this quite heavily (it might even be *faster* than caching the length in a local variable, depending on how the optimizer deals with both cases). The "-server" flag to the Java command also changes the behaviour of the JITC, and needs to be considered (see the java man page).

Back to Array.getLength(Object). This is a true method call, however, it *should* be implemented as a simple accessor to the array length field. The HotSpot JITC *should* optimize the call/return overhead away, and effectively rewrite the calling bytecode to access the length field directly. There is a lot more going on here, so performance might well vary, and be worth a test. The results will probably be dependent on the platform and JVM in use.

You'll notice that there are a lot of "should" weasel words in the above. Whenever you are looking at performance issues there is no substitute for measuring the performance of your own code. So, if you think it is likely to be important, code it the "easy" way and measure how it performs. If it is too slow, find out why (i.e. profile it) and fix it. You might think that this is an awful lot of work to do for every sort of construct one might use in a program. It is. Software performance typically follows the 90/10 rule: 90% of the time is spent in 10% of the code. If the construct you are worried about isn't likely to be in the 10% of the code that does most of the work, don't worry about performance -- write the code to be easy to read, understand and maintain. Knowing what code is likely to be a performance issue has an element of experience to it, and an element of luck. No matter how experienced you get, you will not be able to find all the performance issues up front. You gain the necessary experience by writing poorly performing code, analysing it, and fixing it. Don't spend too much time trying to eliminate all performance issues up front -- design to avoid the obvious ones, and then profile the code. Simulation and prototyping can help you choose algorithms up front to avoid the worst forms of designed-in performance problems.

In my experience with Java, array length access is not a performance bottleneck no matter how you do it.

_______________________________________________
Do not post admin requests to the list. They will be ignored.
Java-dev mailing list      (email@hidden)
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/java-dev/email@hidden

This email sent to email@hidden


Visit the Apple Store online or at retail locations.
1-800-MY-APPLE

Contact Apple | Terms of Use | Privacy Policy

Copyright © 2007 Apple Inc. All rights reserved.