Javamex moved to a new server

The Javamex web site has been moved to a new server. Hopefully the move was fairly transparent to readers, but I of course welcome any feedback in case of any gremlins you may spot...!

iPad for programmers: new section and survey

In preparation for a new section of the site dedicated to programming tools for iPad users, the site contains a survey to find out which tools people are currently using. If you have a few seconds to spare, you are invited to fill in this very quick survey.

What kind of tools are we interested in? Well, essentially any iPad app that you consider to be "programming-related" in some way: for example, code editors, tools to run scripts, calculators that ease with programming-related tasks etc. Even general tools such as VNC clients are also welcome if you use them for programming-related tasks.

Javamex survey

Readers are invited to take 5 minutes out to answer the site's Java programmer survey. The survey asks you your opinion about various aspects of Java programming: how difficult or easy do you consider aspects of Java such as threading, the 'volatile' keyword, using databases in Java etc. The survey is completely anonymous and the results will be used to improve the focus of future articles published on the Javamex web site.

The cost of object orientation: an update

Back in March, an article was added to the site on the performance cost of object orientation which showed that on a test system, "hand-cranking" computationally expensive complex number calculations to avoid the use of encapsulating objects gave a notable performance benefit. The results also showed, however, that the benefit of using mutable objects was limited.

In some work I've been doing more recently on a wider range of test machines and versions of Hotspot, at appears that this effect is not universal: on at least some systems, there is a benefit from using mutable rather than immutable objects. More details will be posted to the site in due course.

The performance impact of object orientation

Today's new Javamex article looks at the performance impact of using an object-oriented approach vs an optimised, non-object-oriented approach in a case where the OO approach requires high object throughput. Specifically, we look at the case of calculations with complex numbers.

The basic tenet is that the most intuitive program design is to have a complex number encapsulated as a Java object, and furthermore, as an immutable object. This means that at each individual step in a calculation, a brand new object is created. However, performance measurements suggest that using immutable objects is only around 28% slower than using mutable objects, whilst the codability and maintainability impact (threading issues; bugs introduced by forgetting to copy objects and hence making accidental modifications to an obejct) may be considerable.

In our example, a version of the algorithm that does away with encapsulation and "inlines" its calculations on raw double primitives is more than twice as fast, as perhaps might be expected. On the other hand, "only" being between twice and three times as fast means that a comparable improvement will be possible in some applications by making use of more processors, or potentially making other algorithm improvements, whilst the codability and maintainability implications of not using encapsulation become more severe for more complex applications.