LO Embedded Firebird/HSQLDB performance comparison

One of the major motivations for my GSOC project this summer was to get rid of the somewhat inefficient use of Java from C++. One immediate difference noticeable from early on when working on Firebird integration is the disappearance of a large pause when loading a database caused by startup of the jvm. (Unfortunately we still need Java for various wizards within Base which still need rewriting in C++/Python/etc. — for now this pause just happens at a different point in time.)

However the main speedup to be expected was in actual manipulation of data. Hence a insertion/retrieval test was developed — currently we only test the insertion and retrieval of 120’000 strings (a dump of the aspell dictionary), the results of which show a significant advantage for Firebird:

graph_firebirdhsqldb

It should be noted that this test is not an accurate comparison of Firebird and HSQLDB in their native environments, this is only an accurate comparison of the two databases accessed via SDBC drivers, i.e. going via C++ — I suspect the slowness of HSQLDB is mostly due to the use of JNI and the C++/Java transition.

It would probably be interesting to add further tests to compare the performance when working with numeric types, however the performance boost of using firebird should already be clear. The tests and documentation can currently be found in dbaccess/qa/unit/emeddeddb_performancetests.cxx.

 

Tagged with: , , ,
Posted in GSOC2013, LibreOffice
2 comments on “LO Embedded Firebird/HSQLDB performance comparison
  1. Anonymous says:

    Excellent stuff. I hope we see firebird used by default with LibreOffice.

  2. Allan Smith says:

    Anxiously awaiting the announcement that Firebird has successfully replaced HSQLDB.

    I’m hoping that the announcement will have a major impact on people’s opinion and use of Firebird.

    I’m at a juncture in my life where I need to make some long-term decisions on where to invest my educational time, whether in Firebird / PHP / Apache or in PostGRE, MariaDB or even MySQL.