... that way is always difficult and error prone. There're rounding errors (dividing long values, for instance) and the garbage collector is possibly kicking in during the test.

Try this one out:

Classes: 1
1 112292.17/463086.43 (ns)
10 718.62/2157.6 (ns)
100 636.96/1973.8 (ns)
1000 57.3/431.0 (ns)
10000 42.54/133.34 (ns)
100000 36.65/115.75 (ns)

Classes: 88
1 424.07/1180.59 (ns)
10 102.43/202.93 (ns)
100 24.09/86.4 (ns)
1000 31.45/115.06 (ns)
10000 24.75/109.38 (ns)


private static void test(Class<?>... types) {
System.out.println("Classes: " + types.length);
Class<?>[] empty = new Class<?>[types.length];
int count = 1;
test(types, count, false);
map.clear();
for (int i = 0; i < 6; i++, count *= 10) {
long common = test(empty, count, false);
long normal = test(types, count, false) - common;
long cached = test(types, count, true) - common;
System.out.println(count + "\t" + (normal/100.0) + "/" + (cached/100.0) + " (ns)");
}
}

private static long test(Class<?>[] types, int count, boolean cache) {
long time = -System.nanoTime();
for( int repeat=0; repeat<100; repeat++ )
{
for (int i = 0; i < count; i++) {
for (Class<?> type : types) {
if (type != null) {
newInstance(type, 0, cache);
}
}
}
time += System.nanoTime();
time /= (long) count;
time /= (long) types.length;
}
return time;
}

Amazingly, the results are all the way round! As Knuth once said: We should forget about small efficiencies, say about 97% of the time: premature optimization is the root of all evil

Well, usually the arrays created for varargs are tiny - and therefor cheap to allocate. WeakReference's aren't free and add a runtime overhead, and when taking multi-threading into account you have to add synchornization / ThreadLocal storage to the game. Furthermore I don't think your test is fair - uncached arrays are also created by reflection - which usually isn't nescessary ;) - Clemens

Have you thought about using A SoftReference instead of a WeakReference. I would think you would want to cache empty arrays as long as possible. In my experimentation weak referenced object only live until the next garbage collection and soft references last until the VM decides it really needs that memory for something else. Also is using WeakHashMap with Class objects seems strange, is this to keep from holding a reference to the classloader?

Hello Sergey, 2 things I'd like to comment: You are using a WeakHashMap with Classes as keys. OK, this allows for custom classloaders to unload classes. But why do you also use WeakReferences as the map's values? If you'd simple put the empty arrays directory into the WeakHashMap you'd gain some performance, and the (finite) number of empty array instances would be freed upon JVM termination! Secondly, you're trying to improve 2 things at once: performance and type-safety. Unfortunately, you cannot replace the non-generic "newInstance" method with a generic one because of the lack of support for primitve types. I suggest you rename the method to "newObjectArray" and add an argument check such as if(type.isPrimitive()) throw new IllegalArgumentException("cannot create primitive array"); to prevent the user from receiving a surprising ClassCastException! Cheers, Gernot

A library is the wrong place for such fix. This could be solved trivially: for each loaded Class (including primitives but not including arrays), allocate a zero-length array of that class and reference it from a private field of the reflection metadata, eg. Class.emptyArray. The memory overhead is relatively tiny (a loaded Class needs a ton of metadata), and the GC could be arranged to ignore the emptyArray field so it doesn't block class-GC but doesn't incur any overhead of using a soft reference (gazillions of soft refs in the heap = hell for the GC). Finally, update the array allocator (the bytecode "newarray" or the equivalent native code produced by the JIT) to just return type.emptyArray when length==0. (That's an extra comparison and branch in the allocator, but this is only necessary for arrays which is a small fraction of all allocations so it's not a sensible hit). The only limitation is for arrays-of-arrays, this can't be handled by the proposed design to avoid an infinite loop (as you load class X it creates a cached X[0], that creates a cached X[0][0], etc.), but that's a minor issue.

Now I know there's a compatibility catch - code relying that new X[0] returns a unique object, not == to any existing object, and with a separate monitor, will fail. I suppose such code should be extremely rare because I can't imagine any non-stupid reason to do that. But perhaps the caching optimization could be optional, enabled by a runtime switch. In the worst case, just create a completely new API, similar to Array.newInstance() but with the caching, and let tuned code (or cleaner languages-for-the-JVM) invoke it. A portable library could use your code in JRE < 7, or just delegate to the new AI in JRE >= 7. Everyone's happy.