After skipping the easter weekend to go snowboarding in Chamonix, I'll continue the EJAPP Top 10 countdown with number 4.

Badly performing libraries are a problem that occurs more often than one would expect. This issue is somewhat similar to the incorrect usage of Java EE in that not enough care is taken in selecting and using a certain technology. Some development teams will happily pile JAR after JAR into their WEB-INF/lib directory or into their POM file, :

• without checking whether that library is really needed (and does not overlap with functionality already offered by other libraries used),
• without checking whether that library can offer good performance or whether a better performing alternative is available,
• without reading the documentation to see how it should properly be used, and
• without defining how the library is going to be used within the application

Examples here are:

• BEA's implementation of the STaX API that is more than two times slower than some of its competitors.
• java.net.URLEncoder that is outperformed up to 90 times (!) by org.apache.commons.codec.net.URLCodec in multi threaded applications (= all web applications).
• Earlier versions of JAMon had bad performance due to repeated allocations of DateFormat and NumberFormat. Ironically, JAMon is a tool to monitor the performance of your application.

Even worse, some development teams will write their own frameworks and libraries where existing ones already exist that offer (nearly) the same functionality and (usually) better performance. Apart from the initial inferior performance, these libraries and frameworks do not evolve as rapidly as existing (free) libraries in terms of performance (and functionality and security and ...). As Linus says: Many eyes make all bugs shallow. Unfortunately, I can't give any examples here as those frameworks are, by definition, proprietary.

In any case, to prevent these kinds of problems, follow these steps when some functionality is needed :

1. Check libraries already used in the project for the functionality.
2. Check existing (free) libraries for the functionality.
3. Only when an existing library cannot be found, implement the functionality yourself. Consider releasing it as free software; the community will benefit and may even offer additional functionality, performance improvements, security fixes, etc.
4. Verify that the selected library can offer the required performance.
5. Read the documentation, newsgroups and forums about proper usage of the library.

And only then use an existing library or build your own.

Filed under Java, Performance | 2 Comments »