Last night I took time to write a stress testing script for Radio's object databse to see how it performs in massive insert situations. It performed amazingly well. The script I wrote generated a file full of garbage and wrote it to disk. Once on the disk, it opened it back up and inserted all of the data into the object database. Each line in the file was not necessarily delimited in any way, so it had to search the string for the correct segments and put the segments into the appropriate tables. The file I ended up using had 400 lines in it. It took about two seconds to run on a 300MHz Compaq Armada 7400 with 128MB of RAM. However, I was not timing the script, though it would be easy to add timing. This is not a bad ratio of inserts per second, about 200 inserts per second. I may try a larger file later to see how this ratio changes.
This is not the interesting part. While executing this script, Radio.exe chewed through my CPU but did not consume more memory. This is great! When massive inserts occur like this in a RBDMS, both CPU and massive amounts of memory are consumed, even with the advanced memory control features in Oracle and MS SQL Server. This was not the case with the Radio object database. While Radio is running massive inserts like this any application that is currently running should remain decently responsive.
Great engineering, Userland!
