[ANN] db4o (database for objects) object database for .NET CompactFramework v. 2.7

[Carl Rosenberger]

Hi all,

after receiving very valuable help here, I would like
to inform you what it was good for:

We have just released our object database engine in
a version that runs on CF.

I believe that we supply the only product of the kind
for this platform. Please correct me if I am wrong.

Feel free to download a trial version from our website:
http://www.db4o.com
A half an hour should be sufficient to understand the
concept of db4o and to get your first application
running.


Here is a very short paragraph about the capabilities
of db4o:
db4o is a client/server object database written in C#,
accessible from all .NET languages. Features include
ACID transactions, query-by-example, S.O.D.A. object
query API, WeakReference object identity management,
and automatic class schema recognition. db4o comes as
a 250kB small-footprint .DLL and can be run on the
CompactFramework. The key benefit of db4o is it's
simplicity: One line of code stores any object.


db4o is written and maintained in Java. With the help
of our own automatic one-click Java-to-C# converter
we are able to deploy proved and tested quality to .NET.


Our Java version is being used in the first integrated
control system for highspeed trains. I think this
proves the scalability of our product:
Simplicity works equally well on PDAs and on huge
multi-processor systems.


Thank you all very much again for all the help that I
received here. Very special credits go to Alex Feinmann
for his great support.


Kind regards,
Carl

 

[Alex Feinman [MVP]]

Carl,

I wonder what kind of footprint your Java version has?

 

[Carl Rosenberger]

Carl,

I wonder what kind of footprint your Java version has?

Alex,

do you mean the size of our engine?

The Java version is a 253kB Jar.
The .NET version is a 244kB DLL.

If you are interested in a comparison of the efficiency of
IL vs. Java Bytecode:

I would expect between 30kB and 40kB of the .NET DLL to be
occupied by our Java-to-C# wrappers.

It's hard to tell from the size of the sources, since the
.../src/j4o/ files have some comments, whereas the
.../src/core/ do not.

An accurate approximation may be possible with a LOC tool.

For me .NET wins the size race with a ratio of about 4:5.


You may be interested in a comparison of the performance as well.
Since I just noticed that the old .NET benchmark code does not
correspond to the current Java code, I quickly ran the Java code
through our converter. For anyone that would like to experiment
himself, I put it on our server:
http://www.db4o.com/db4o/bench.net.2.7.1.zip

(Of course you would need the full download of the .NET
version also, and possibly the Java version for
comparison tests.)


Here are the results on my machine:

..NET 1.1
db4o - 3000 objects stored for ID retrieval: 440 ms
db4o - 100 instantiations from 3000 objects by ID: 10 ms
db4o - 100 complex inserts: 40 ms
db4o - 100 complex selects: 811 ms
db4o - 1000 int inserts: 60 ms
db4o - 50 scans on 1000 int: 2163 ms
db4o - 10 updates on 1000 int: 831 ms
db4o - 1000 String inserts: 201 ms
db4o - 50 scans on 1000 string: 3094 ms
db4o - 10 updates on 1000 string: 1232 ms

Overall db4o performance: 9343 ms


Sun Java 1.4.1-b21 Client VM
db4o - 3000 objects stored for ID retrieval: 591 ms
db4o - 100 instantiations from 3000 objects by ID: 20 ms
db4o - 100 complex inserts: 30 ms
db4o - 100 complex selects: 561 ms
db4o - 1000 int inserts: 40 ms
db4o - 50 scans on 1000 int: 1262 ms
db4o - 10 updates on 1000 int: 751 ms
db4o - 1000 String inserts: 131 ms
db4o - 50 scans on 1000 string: 1722 ms
db4o - 10 updates on 1000 string: 1072 ms

Overall db4o performance: 6740 ms


The above certainly is not fair for .NET. Our code was
heavily optimized for Java with JProbe, a very good and
mature profiling tool.


The .NET version has to run through our Java-to-C# wrappers,
but I wouldn't expect that to take too much time.

I think that we loose a lot more because our code contains
some unnecessary type conversions that we introduced
generically to replace Java primitive type wrappers.
Some code looks like this:

public override Object read(YapBytes yapbytes) {
int i1 = readInt(yapbytes);
return System.Convert.ToInt32(i1);
}

instead of

public override Object read(YapBytes yapbytes) {
return readInt(yapbytes);
}


However the few profiling runs we did with AQTime only
showed hot spots in file access, which I think is a very
good sign that our .NET code is not so much worse than
our Java code.


By the way:
We used the AQTime demo version and we are considering to buy
it. Is this the most recommenable profiling tool for .NET?

Is there any tool that can profile applications on CF?


Kind regards,
Carl