String str = "Hello";
str = str + world;
str = str + "!";

Why not?

It’s really slow when you do it a lot!

What should you do instead?

Use the append(String) method in StringBuffer (Java 1.4.2 on), or StringBuilder (Java 5 on). StringBuilder is slightly faster than StringBuffer, but is not thread safe. Both are much faster than concatenating String objects – by orders of magnitude. For example:

StringBuffer str = new StringBuffer("Hello");
str.append(world);
str.append("!");

I set up a simple test rig to concatenate ints onto a String in a loop, by simple ‘+’ concatenation, then with a StringBuilder. Running a half dozen times and taking a rough average, the results are pretty conclusive – concatenating the wrong way can really slow things down.

• Over 10,000 repetitions, ‘+’ takes around 650 times as long (670 ms vs. 1ms).
• Over 20,000 reps, it takes around 1,800 times longer(3,500ms vs. 2ms).
• Over 100,000 reps takes around 41,000 times longer! (over 5 minutes vs. 8ms).

Why’s it so slow?
Strings in Java are immutable, which means that once a String is instantiated (be it by new String() or as a literal “blah”) it cannot be changed. When you concatenate one String to another, you actually create a third String which is the result of the concatenation

Not too much of an overhead, except when that concatenation is in some nested loop structure or the like and becomes a real bottleneck in your code. In that situation, you’re creating loads of objects that you’ll never use again and you’ll probably be running the Garbage Collector a lot to mop up, which makes things go even slower.

I first came across this when I got caught out building a big HTML table from database query results. When I was using String concatenation, it ran like a dog and the speed was pretty obviously dependent on the amount of concatenation going on. Read up on it, switched to StringBuilder, and the processing to put the String together went (in the worst case) from taking minutes to milliseconds. That’s the kind of performance improvement people notice.

There’s a little more to it, and if you’re interested, there’s more info and further optimisation steps here. The SCJP 5 qualification also covers this and a load of other simple gotchas in Java SE.

Relative and Absolute Links

You’ll put the pictures on your page using HTML’s img tag, and it probably looks a little like this…

<img src="my-picture.jpg" />

HTML is rendered by your browser, so you can ignore your PHP or anything else happening in your server – the good stuff is happening right there on your desktop. You’ve just told the browser to grab an image file called my-picture.jpg from the same directory that your HTML page is in. That’s fine if that’s where the picture happens to be, but if your other pages use the exact same tag and aren’t in the same directory, they’re not going to be able to find it.

How can you tell it’s a relative link? Because that src attribute’s value doesn’t start with a / (forward slash) character. That looks like this…

<img src="/my-picture.jpg" />

The browser will now look for the my-picture.jpg in the Document Root of your website. (that’s configurable, but normally it’s a directory called www or htdocs) It’s called an absolute link, because the browser will look in the same place regardless of where the HTML file being rendered happens to be.

Absolute links can also start with http:// and define the whole URL, for example…

<img src="http://crossedstreams.com/img/common/banner.gif" />

…handy if you need or want to point to a file that’s actually on a different webserver. If you’ve not done it before, try and use the image resource in the above example in your own HTML page.

Other Relatively Absolute Stuff

There’s a little more to relative links than just loading from the same directory as your HTML though. You can specify any location you have access to relative to the HTML page. To specify a sub-folder, use forward-slash – so if there was a folder called images in the same place as your HTML and the picture was in there, your original link would look like…

<img src="images/my-picture.jpg" />

You can also walk up the file structure, using ‘../’ to mean ‘up one level from where the HTML file is’.

The same principle applies to any tags with a src attribute – the browser loads the the file, and the relative vs. absolute thing applies. If you get into JavaScript, then you’ll probably write your fancy scripty stuff in a file on its own, and then use the <script> tag with a src attribute to get your browser to load the script content from the file into your page. HTML anchors (the <a> tag) use href as an attribute, which also specifies a relative or absolute location.

Decisions, Decisions…

So which should you use? As with pretty much anything else to do with computers, it depends.

Absolute links are easier to understand because you don’t need to think about where the page being rendered happens to live – the downside is that you can’t deploy the website feature that uses those files as a nice neat tar or zip archive.

You’d use relative links if you needed to package up your snazzy new file upload feature or whatever so that it could just be deployed onto any site – however if you do use relative links, you have to be careful where you put your HTML files so that those links work.

And on the Server-Side

Although in the case of problems with these HTML tags, anything happening on the server-side (most likely PHP or PERL code that’s writing out the HTML to be sent to the browser) is a red herring, the same relative vs. absolute path idea applies for resources you’re including in your code. In this case, the equivalent of Document Root is ‘/’ for UNIX-type systems and something like ‘C:\’ for Windows, but the same stuff applies as to how you can locate resources you need when your code runs.

That’s all Folks

That’s all I got on the subject – try googling relative and absolute for other perspectives. Hopefully if you found this post it was of some use to you. Have a good one!