How-to speed-up your java code myths

In my last post I covered tips that I  have collected trough out the years on how to speed up your java code,

After reviewing the tips and reading my friends criticism, I updated the list and created a new list of myths, here it is:

final: developers might think that final methods are more efficient due to the fact that the compiler will be able to inline those methods. it’s false, imagine that you are compiling the class Main with the class Inline, the non static method Main.main() creates an instance of Inline and invokes the method inline.finalMethod() which is final. on compile time everything looks great, yet in runtime we might use a different version of the compiled Inline class whereas the finalMethod is not final and can be overwritten….

Synchronization blocks: old VMs used to pay a lot of overhead for running a synchronized method, new VMs mostly knows how to trace a synchronized method that is not running concurrently and treat it as a non-synchronized one.

Calling the garbage collection manually: calling the garbage collector manually (System.gc()) is usually a mistake, the new VMs garbage collection mechanism are state-of-the-art and most likely it will invoke the GC on a better timing. moreover manual GC triggers a full collection of all generations -> that’s not a smart move.

Object pooling: allocating object on the heap is not cheep but for non-complex objects it’s not that expensive as well, design an object-pooling for simple object will cause an over-head of managing the pool  in many cases.

In general it seems like performance tips should always be revisited since new compilers and VMs try to solve exactly those problems.

Immutable objects: in general immutable objects has many advantages (1) automate thread-safety (2) their hashCode value is cacheable (3) easy to work with

a quote from Effective Java: “Classes should be immutable unless there’s a very good reason to make them mutable……..If a class cannot be made immutable, limit its mutability as much as possible.”

Google Gears vs. JDBC (performance)

This year I’m teaching a course in the Hebrew University (advanced Internet technologies), I’m currently guiding one of my students, we are designing a web framework that heavily uses the abilities of Google Gears, I will elaborate about this project on a future post.

I must share with you a performance testing that we have been doing in order to proof the concept of client side database efficiency.

As I belong to the Java/J2EE school, I compared a JDBC method to a Javascript function that uses the Gears API (mainly the Database object)

My test case was simple, creating a new simple table with one column(int), inserting N rows(increasing number from 0 to N-1), selecting * from that table and finally iterating the result one by one.

In order to isolate the database connectivity problem from few multithreading issues I have used IE8 to test the javascript code ( and not chrome or FireFox).

The results are unbelievable:

The X axis represent N (the number of rows I have inserted), the Y axis represents time(ms).

Gears is working faster then JDBC!

Few issues I had:

1) This is happening only when I wrap the gears code with a transaction ( I think it’s not an issue due to the nature of a client side programming. no more than one concurrent user), (thanks to the Gears team for helping me here..)

2) Of course you can claim that JDBC is just an underneath layer and it can be work under a 2nd level cache layer, well we can defiantly implement a 2nd level cache for Gears as well as part of our framework 😉

3) Why IE8?  Chrome and maybe firefox 3.5 are working differently with threads and I did not want to add code that deals with threads (WorkerPool)

4) I have used the MySql database to test the JDBC code.

5) Gears code:

function db(numOfRows) {
var currentTime = new Date().getTime();
var db = google.gears.factory.create(“beta.database”);
db.open(“gearsDb”);
db.execute(‘BEGIN’);//start tx
db.execute(“delete from data”);
db.execute(“create table if not exists data (rowId int)”);
for(i=0;i<numOfRows;i++)
db.execute(“insert into data values (“+i+”)”);
db.execute(‘COMMIT’);
var rs = db.execute(“select rowId from data”);
var val = 0;
while (rs.isValidRow()){
val = rs.field(0);
rs.next();
}
rs.close();
var currentTime2 = new Date().getTime();
currentTime2 -=currentTime;
document.write(currentTime2+”,”+numOfRows+ “<BR/>”);
}

6) JDBC code:

long time = System.currentTimeMillis();
DriverManager.registerDriver(new Driver());
Connection con = DriverManager.getConnection(“jdbc:mysql://myLab:3306/jdbcPerTest”, “root”, “pass”);
PreparedStatement stmt = con.prepareStatement(“insert into data values (?)”)
con.setAutoCommit(false);
stmt.execute(“delete from data”);
for(int i =0 ;i<param;i++){
stmt.setInt(1, i);
stmt.execute();

}
con.commit();
ResultSet rset = stmt.executeQuery(“select * from data”);
int result = 0;
while (rset.next()) {
result = rset.getInt(1);
}
long time2 = System.currentTimeMillis();

System.out.println(param+”,”+(time2 – time));

rset.close();
stmt.close();
con.close();

For me such a results are a begining of an era, yet post factum those results are obvious..

If you had like to join such a web framework development please let me know..