db4o database files are structured as used and unused slots internally, very much like a file system. Just like a file system, a db4o file can become fragmented, which means it may become larger than it would have to be. This also can have a negative affect on (file access) performance, so it is advisable to defragment database files on a regular basis.

As of version 6.0 db4o provides a new defragment mechanism. While the old mechanism would instantiate live objects to transfer them to the defragmented database file, the new version operates directly at the slot/file level, avoiding any reflection or object instantiation calls.

According to our internal benchmarks this results in a performance speedup of 4x up to 14x, depending on various factors ranging from OS/VM version through the individual database structure to custom defragment configuration. For more complex and deeper graphs we suspect that there can be much larger performance improvements than in our benchmark. Please let us know about your results.

For the general case, usage is as simple as calling

com.db4o.defragment.Defragment.defrag();

...which will move the original file to a backup location and create a defragmented version in the original location. Those of you who would like to have more fine-grained control over the defragmentation process, please refer to the API docs.