When writing realtime applications optimal code is always the goal. But it’s hard to always know exactly what is going to be “expensive” in terms of CPU time.

Java Performance Tuning is a very comprehensive optimization resource, but a bit too dense for less experienced programmers. JavaWorld has an article called Make Java fast: Optimize!, which is more accessibly and explains some basics quite well. More importantly, it provides a benchmark applet that gives an overview of the relative CPU cost of basic Java instructions.

For instance, the assignment “int x = 0″ would take 987 picoseconds to execute a certain number of times, while “x[0]=x[10]” would take 1304 picoseconds. See below for benchmark examples.

There is also the classic Jonathan Hardwick optimization tutorial, which is a bit more technical. It’s old (1998), but the basic concepts are still valid. One thing he warns against is the cost of object instantiation. Creating a new object instance can be expensive, particularly if it’s a complex object with lots of data. Try recycling complex objects rather than creating new ones.

Keep in mind that spending tons of time optimizing single lines of code is usually not worth it. Small differences in the benchmarks below would only matter if you’re doing some calculation a huge amount of times. Try using a profiler if you have the time and the need to figure out which parts of your program suck CPU cycles.

Otherwise, some basic rules of thumb should get you a long way:

• Don’t calculate values more than once. Instead, store them in a local variable for reuse.
• Avoid creating new complex objects when you could recycle old instances instead.
• If possible, use simple data structures. A one-dimensional array is faster to access than a two-dimensional one.
• If you’re doing work with Strings, consider using StringBuffer to avoid instantiating temporary String objects.

Read the rest of this entry »

Update: This hack is obsolete as of 0133. Read more here.

For those of you who have been using the hack I posted a while back to force anti-aliasing in Processing, here’s an updated version for Processing 0125. According to the source repository Ben has been fixing lots of little things in PGraphicsOpenGL, so it’s worth updating.

The hack is actually lying dormant in the PGraphicsOpenGL source, but it’s been commented out with the note “how to integrate this properly?”. Obviously, having to set hardware-specific settings goes against the ease of use that Processing is known for. I guess Ben and Casey are just trying to find a way to include it in a manner consistent with the rest of the application.

To use the hack simply download the ZIP archive below and unpack it to produce the hacked “opengl.jar” file. Drop the JAR into the “libraries\opengl\library” subfolder of your Processing application directory. Make sure to make a backup of the original opengl.jar. Once replaced, the new PGraphicsOpenGL class always initializes with 4x supersampling.

• OpenGL hack for version 0125: opengl-hack-0125.zip.
• OpenGL hack for version 0124: opengl-hack-0124.zip.

Next week I’m not teaching, so instead I want you to work on the exercises given below. You will have a teaching assistant and maybe sometimes Mosse to help out. Also, the Urban Interface conference is warmly recommended. It’s free, but you should sign up for it in advance.

1. Social software: Sign up for Flickr. Join the AHO Interaction Design group. Post a link to your blog there.
2. Social software: Find 3 blogs you like that are related to interaction design. Post the links to the AHO Interaction Design group. Set up a feedreader like Google Reader, Newsgator or similar and subscribe to the feeds of those blogs.
3. Random composition (EX02): Create two compositions. One should be based on principle of order and regularity. The other should manifest chaos. Be particular about color. Consider transparency as a way to add depth. Save a representative image from each sketch and post them to Flickr. Prefix the filename with “EX02″.
4. User interaction (EX03): Create a drawing tool where the gesture of the user is used to draw images. Don’t be literal, but rather interpret the user’s input to control a dynamic drawing system. The user should still have a sense of control, however. Draw a representative image and post them to Flickr. Prefix the filename with “EX03″

For the next month I am teaching a foundation in computational aesthetics at Oslo School of Architecture and Design (AHO). Files from the lessons can be found here:
workshops/070905_aho/

There is also a new Flickr group that we will use to support the work:
Flickr: AHO Interaction Design.

Spiegel Online has just published a feature on generative art: Kunst aus dem Computer: Malen nach Zahlen (in German). It features work by myself, Neil Banas (who was blogged on Generator.x a while back) and San Base.

The opening paragraph strangely proclaims that “Marius Watz is always afraid.” (Marius Watz hat ständig Angst.) That seems to be a slighthly overenthusiastic interpretation of a comment I made about the importance of backup and having access to data while travelling. It also states that I’ve exhibited in Los Angeles, which I haven’t.

The rest of the article seems ok, if a tad superficial. In particular, I think the issue of whether or not generative art can be sold is a bit more resolved than it comes across in the article. The answer is yes, of course it can. The main challenges here are reaching collectors and museums, as well as to make sure the work is collected in a form that can be maintained for posterity.

See the following two articles at Artinfo for some pointers on the subject of selling and collecting media art:

• Code in a Box
• Conserving Pixels, Bits, and Bytes

Thanks to Christina Vassallo for providing me with these links in the first place.