NeoDatis Benchmark on Android

After doing a lot of different testing and trying a lot of different settings I finally decided to do some testing. I had some heap size memory when doing the complete TestIndex test with all of the 10000 records, NeoDatis like to store all of entries in it's internal cache, so I settled with 1000 for now, until I can figure out a way to get around the memory related issues.

Here are the result table:

	Perst	SQLite	DB4O	BerkeleyDB	NeoDatis
Insert	1159	6892	4168	4619	25022
Search	599	9481	18261	3405	18325
Iterate	120	290	4392	2889	11126
Delete	1659	6315	7084	5565	10156

It should be noted that the NeoDatis team releases new versions often, so if you have some problem, it might be fixed in a new version.

JODB (Java Objects Database) for Android (3) with reduced TestIndex benchmark

While creating and running the TestIndex for JODB I've discovered a few things.

• Search operations are slow, and scale with the amount of records that is present in the database, so if it tok 2 seconds to get 10 distinct records with 100 records it will take 200 seconds with 10000, which are the number of records currently used in the TestIndex test. So large record-sets are not a good idea.
• It seems to use a very little amount of memory, but when searching goes as it goes, that doesn't really help that much when things take as much time as it does.
• As mentioned before it only supports primitives as indexes, so one really can't do a full TestIndex test.

As search operations was so costly I though I run a very reduced test with 100 records just to see how all of the other database management systems (DBMS).

As we see search operations are costly, my guess to why they are so costly is the way that JODB interacts with files on the system. I think that it do a lot of input/output (IO) operations when it does it's search operations. From what I gathered from looking in the source code it uses a FileChannel object to access its database files, which just reads or writes on a specific part of a file. So when doing a search operation it will read through the file until it finds the "part" (Record) that we are interested in. This would also explain why it use so little memory when it is running.

	Perst	SQLite	DB4O	BerkeleyDB	JODB
Insert	106	586	278	354	2183
Search	48	889	989	334	31021
Iterate	14	36	238	192	718
Delete	115	498	415	465	1011

TestIndex on Android developer phone1(ADP1) with Berkeley DB

After a long day of testing I got some results on the ADP1. BerkeleyDB does seem to like heap space more than the other database managament systems(DBMS), but it seems to be able to run ok. I think I'll need to think about ways to shrink the memory usage of the different tests.

Well here are the results:

	Perst-ADP1	SQLite-ADP1	DB4O-ADP1	BerkeleyDB- ADP1
insert	21150	600824	88059	113668
search	16176	107514	470561	74417
iterate	11747	6777	90657	62190
delete	37704	562522	155778	215499

TestIndex on Android emulator now also with BerkeleyDB

It's taken a bit longer time than I had expected to get some TestIndex results for BerkeleyDB on Android. A while back I had a running version up and running, but managed somehow to messup the serialization part, so I had to create a new version from scratch that does not use serialization. Instead I used BerkeleyDB's custom TuppleBinding which gives somewhat better performance than serilization. I hope to soon be able to post results using serilization as well, to compare the difference in performance. I will also do some research into the other database management systems that I have tested to see if they have similar optimalizations that can be used.

Results from the test in milliseconds.

	Perst-Emu	SQLite-Emu	DB4O-Emu	BerkeleyDB-Emu
insert	15158	72426	46648	55698
search	12480	100528	290541	37612
iterate	8365	5157	51335	29484
delete	25100	65498	93396	100455

BerkeleyDB for Java on Android

After having tried a couple of databases on Android I thought it would be nice to add another one to the bunch. So after a little searching I found BerkeleyDB for Java, downloaded it and tried to run it on the Android emulator. To get it to work with Android there are some instruction in a HowToAndroid.hmtl file that's bundled with the documentation. It describes the required modifications that are needed to do to the source in order to get it to work. There are a couple of folders that need to be deleted and some extra java files that need to be created, but all-in-all it's quite manageable. After doing the required modification to the source of BerkeleyDB I tried to run a sample small sample that I had for BerkeleyDB and ended up with this exception: "com.sleepycat.je.log.LogException: (JE 3.3.87) java.io.FileNotFoundException: /data/je/je.lck". I concluded that this had to do with BerkeleyDB's need for a folder to store it's enviroment(database files, logs). BerkeleyDB requires you to create this folder, or else you will need end up with the lovely exception above. In the how to there is some instructions on how to create the environment( folders ) for BerkeleyDB, "adb shell mkdir /data/je" and removal of the folder by "adb shell rm /data/je/*". This is a bit quirky, and leaves you with the responsibility of cleaning after you application, as the folder is directly placed in the data folder and not in the "home" folder of your application. So I'd recommend using the Activity.getDir("folderName", 0) or something similar to create the directory for BerkeleyDB, so that it will be cleaned up when the application is removed. So sum it all up I got it up and running and in a couple of days I'll post some results from the benchmark.