Some Post JavaOne Fun

It's friday night.  Finally back at the hotel without a meeting or party or a session to go to.  What else is there to do but port benchmarks of debatable value to my favorite new non-Java language:  Fan.  Earlier in the I was directed to this blog post detailing some performance problems with groovy.  Yes, I know the blog is old.  That's not the point I want to make here.  This week at Javaone, there was a presentation doing some more performance comparisons between languages on the JVM.  This one caught my eye because it's the first one I've seen in the wild that included Fan.  So this got me thinking about year old post and the ray tracing exercise.  How would fan hold up?  I decided to find out.  Because there's no better way to spend a Friday night after long conference week, right? The Fan code isn't idiomatic (I'm not that bored tonight).  It's just a quick and dirty port from the Java source to Fan.  For reference, I reran the Java version and then the Fan version.  This test is running on OS X and Java 1.6u13.  Without further hand waving, here's the results:

time java -cp . ray 8 512

real	0m14.210s
user	0m12.443s
sys	0m1.313s

time fan tracer::RayTest 8 512

real	0m17.700s
user	0m15.832s
sys	0m0.672s

As you can see, the performance is really quite good. I'll probably play with the source over the next few days and see if I can't improve it a bit. The fan code is pretty rough so there's probably a fair bit to be done to speed that up a bit.  I'll attach the source so if anyone else is interested the source will be available.  I have to say, though, that's not too shabby at all.

The Kindle is Here!

I finally broke down and bought a Kindle.  I've been eyeballing them since the first one came out and have been daydreaming about them since the Kindle 2 pics first leaked.  After reading countless previews and reviews and raves and rants, I decided it was time.  Sure, it's expensive.  Yeah, it's "only a single function device."  blahblahblah.  The fact is I love to read, I live in a NYC apartment, and I already have an entire wall devoted to bookshelves crammed full of my books.  There's just not that much space here to keep buying more and more books.  Any my library hardly ever has what I want on the shelf.  When they have it at all, there's a waiting list.  So this makes a lot of sense for me in a number of ways.  I've had it for about an hour now so I don't have any deep dive experience with it as such, but as far as first impressions go, it's a big win.  And the first thing I did after browsing through the user's guide?  I bought Brandon Sanderson's latest book "The Hero of the Ages." Now if only I didn't have to work.

String Concatenation Revisited

I had intended to do some follow up numbers to my previous post but I got a bit sidetracked by work and the like.  My simple tests all work with one String that's created then thrown away.  This test helped me resolve the question I had when I started down that road but stops short of a more general answer.  Then I saw this pingback which led me here.  There's some nice analysis and insights to consider.  So given the shortcomings of my little benchmark and the comments there, I wanted to expand my test a bit and see what things look like when the loop doesn't throw away the data.  The test is simple enough again:

import java.util.*;
import java.text.*;

public class ConcatenationTest {
	private static long concat(int count) {
		long start = System.currentTimeMillis();
		for(int x = 0; x < count; x++) {
			String s = "Loop " + x + " of " + count + " iterations.";
		}
		return System.currentTimeMillis() - start;
	}

	private static long append(int count) {
		long start = System.currentTimeMillis();
		for(int x = 0; x < count; x++) {
			String s = new StringBuilder("Loop ")
				.append(x)
				.append(" of ")
				.append(count)
				.append("iterations.")
				.toString();
		}
		return System.currentTimeMillis() - start;
	}

	private static long concatAcrossLoops(int count) {
		long start = System.currentTimeMillis();
		String s = "";
		for(int x = 0; x < count; x++) {
			s += "Loop " + x + " of " + count + " iterations.";
		}
		long time = System.currentTimeMillis() - start;
		System.out.println("concatAcrossLoops time = " + time);
		return time;
	}

	private static long appendAcrossLoops(int count) {
		long start = System.currentTimeMillis();
		StringBuilder s = new StringBuilder();
		for(int x = 0; x < count; x++) {
			s.append("\nLoop ")
				.append(x)
				.append(" of ")
				.append(count)
				.append("iterations.");
		}
		long time = System.currentTimeMillis() - start;
		System.out.println("appendAcrossLoops time = " + time);
		return time;
	}

	public static void main(String[] args) {
		int count = 10000;
		List concats = new ArrayList();
		List appends = new ArrayList();
		List concatsAcross = new ArrayList();
		List appendsAcross = new ArrayList();
		for(int x = 0; x < 10; x++) {
			concats.add(concat(count));
			appends.add(append(count));
			concatsAcross.add(concatAcrossLoops(count));
			appendsAcross.add(appendAcrossLoops(count));
		}

		String header = "concats   appends   concats across loops   appends across loops";
		String format = "%7d %9d %22d %22d\n";
		System.out.println(header);
		for(int x = 0; x < 10; x++) {
			System.out.printf(format, concats.get(x), appends.get(x), concatsAcross.get(x), appendsAcross.get(x));
		}
	}
}

And then the results:

concats appends concats across loops appends across loops
48 14 18990 1276
27 11 14581 1442
4 4 13206 1253
3 3 13478 1438
4 4 12651 1444
4 3 12485 1403
4 3 12608 1318
4 3 13152 1312
3 4 12535 1390
4 3 12444 1329

Notice after the first two loops the numbers for all runs drops. As the JIT compiler kicks in, we get some optimization but as you can see concatenation across loop iterations is incredibly much more expensive. In this case, StringBuilder is still the clear winner.

update There was a typo in the original test. I was calling toString() in the appendsAcrossLoop test which was entirely unnecessary. (I forgot to remove that call when adapting from the earlier iteration.) The new results are below. I included them here rather than just replacing the table above as it shows just how expensive that toString() is.

concats appends concats across loops appends across loops
42 15 16562 4
5 8 12564 5
4 3 11601 2
4 2 11141 2
4 3 11025 3
3 3 11260 3
3 3 11062 3
3 3 11738 2
4 2 11078 2
4 2 11130 3