I see. Well, the advantage is that it is officially maintained.
Oracle once offered me to include my .NET API, but under the condition that I rewrite it in C++/CLI.
Since this is precludes any use under Mono, I did not feel it was the right way.
However, I have to admit that the current approach (P/Invoke) is a lot more work to maintain, as I have to carefully match the binary layout of the native structs for each new release.
Karl
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I guess a follow-up question, is once you create the .Net dll of the BDB jar, are there any dependencies left? Or do you just need the newly created dll and that's it? Pretty cool if that's it, I'll look into it more to see if there's any benefits...
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Well,...I spent about a half day playing with my new Berkeley DB Java Edition DLL that was cross-compiled using IKVM...I ran some tests to compare with the native .Net DLL downloaded here. For reference purposes, I was using the je-3.3.75.jar downloaded from the Oracle website.
Some notes:
- I only used the Base API of the cross compiled library to test puts/gets. To use the DPL, I would have had to jump through some more hoops and didn't feel like doing that. The DPL is slower anyways, so why bother?
- My test was comprised of writing/reading 100,000 records. Each Record was approximately 250bytes before serializing any data. Everything was single-threaded, done on a 2 year old laptop. (So don't take these numbers to prove anything about absolute performance, but rather just a performance comparison on similar hardware).
- Data was serialized/deserialized using custom BinaryReaders/Writers rather than using the .Net BinaryFormatter which tends to be bloated.
- When using the cross-compiled java dll, I achieved a Write time of about 4200 writes/sec and a Read time of about 11,100 reads/sec. Not bad I thought. I know Berkeley DB is capable of incredible read/write times, but I thought this was sufficient on my laptop.
- I then ran the test using Karl's native .Net dll. Let's just say it blew away the java dll. I expected better performance, but didn't realize how much faster it would be. I achieved write times of about 25,000 writes/sec and 55,600 reads/sec. WOW!
- But Wait, there's more...I noticed that the cross-compiled library was creating multiple database files...surely this had to slow the process down? So I went max to change the max log file size to accomodate all the data in a single database....but alas, the improvements were negligible at best for both read and write times...
- Finally, what I found strange was that for identical data and classes, the cross-compiled java library wrote about 32MB to disk for my test while the native .Net DLL wrote about 55MB to disk. That is a HUGE difference and will be something I keep an eye on for future tests if disk space is an issue for me.
Lessons Learned:
- IKVM rocks! It truly does provide a nice cross-compiler for java libraries. It worked as advertised, and I had no issues with the created .net dll.
- If you truly want to use the latest binaries provided by the BerkeleyDB team, then IKVM seems like a respectable solution...especially when performance is not the most important matter.
- I think for the time-being, I will be sticking to the native .net dll provided here. At the end of the day, speed is of the essence, and I don't see that there is anything missing at this time that I need with the java version.
- I might continue to run some more tests, as I will be needing transactions, so I'd like to get a feel for that as well with both libraries.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I think the differences are mostly due to the fact that the .NET library simply wraps the native Berkeley DB C library. The proper comparison would have been with the Java wrapper for the same native C library, which is not the same as BDB Java Edition - the latter being written in pure Java.
I am not sure if IKVM would work as well with the Java wrapper, as there is JNI involved, but if it did, you would have very likely better performance.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Karl,
Have you tried cross-compiling the Java API (db.jar + dbxml.jar) with IKVM?. It seems to work fine although I haven't used it much yet.
IKVM is a great product, I use it all the time with Saxon XSLT/XQuery.
--
Max
No, I didn't try it.
Does the result not look or feel Java-ish?
It does, PascalCase for Types, camelCase for members, no properties. I don't mind though...
I see. Well, the advantage is that it is officially maintained.
Oracle once offered me to include my .NET API, but under the condition that I rewrite it in C++/CLI.
Since this is precludes any use under Mono, I did not feel it was the right way.
However, I have to admit that the current approach (P/Invoke) is a lot more work to maintain, as I have to carefully match the binary layout of the native structs for each new release.
Karl
Has anyone seen any performance advantages/disadvantages to using IKVM?
I guess a follow-up question, is once you create the .Net dll of the BDB jar, are there any dependencies left? Or do you just need the newly created dll and that's it? Pretty cool if that's it, I'll look into it more to see if there's any benefits...
Please let me know how IKVM works out for you.
Will Do...I'm excited by the possibilities...I'll try to report back once I have more details...
Well,...I spent about a half day playing with my new Berkeley DB Java Edition DLL that was cross-compiled using IKVM...I ran some tests to compare with the native .Net DLL downloaded here. For reference purposes, I was using the je-3.3.75.jar downloaded from the Oracle website.
Some notes:
- I only used the Base API of the cross compiled library to test puts/gets. To use the DPL, I would have had to jump through some more hoops and didn't feel like doing that. The DPL is slower anyways, so why bother?
- My test was comprised of writing/reading 100,000 records. Each Record was approximately 250bytes before serializing any data. Everything was single-threaded, done on a 2 year old laptop. (So don't take these numbers to prove anything about absolute performance, but rather just a performance comparison on similar hardware).
- Data was serialized/deserialized using custom BinaryReaders/Writers rather than using the .Net BinaryFormatter which tends to be bloated.
- When using the cross-compiled java dll, I achieved a Write time of about 4200 writes/sec and a Read time of about 11,100 reads/sec. Not bad I thought. I know Berkeley DB is capable of incredible read/write times, but I thought this was sufficient on my laptop.
- I then ran the test using Karl's native .Net dll. Let's just say it blew away the java dll. I expected better performance, but didn't realize how much faster it would be. I achieved write times of about 25,000 writes/sec and 55,600 reads/sec. WOW!
- But Wait, there's more...I noticed that the cross-compiled library was creating multiple database files...surely this had to slow the process down? So I went max to change the max log file size to accomodate all the data in a single database....but alas, the improvements were negligible at best for both read and write times...
- Finally, what I found strange was that for identical data and classes, the cross-compiled java library wrote about 32MB to disk for my test while the native .Net DLL wrote about 55MB to disk. That is a HUGE difference and will be something I keep an eye on for future tests if disk space is an issue for me.
Lessons Learned:
- IKVM rocks! It truly does provide a nice cross-compiler for java libraries. It worked as advertised, and I had no issues with the created .net dll.
- If you truly want to use the latest binaries provided by the BerkeleyDB team, then IKVM seems like a respectable solution...especially when performance is not the most important matter.
- I think for the time-being, I will be sticking to the native .net dll provided here. At the end of the day, speed is of the essence, and I don't see that there is anything missing at this time that I need with the java version.
- I might continue to run some more tests, as I will be needing transactions, so I'd like to get a feel for that as well with both libraries.
Thanks for the feedback - very informative.
I think the differences are mostly due to the fact that the .NET library simply wraps the native Berkeley DB C library. The proper comparison would have been with the Java wrapper for the same native C library, which is not the same as BDB Java Edition - the latter being written in pure Java.
I am not sure if IKVM would work as well with the Java wrapper, as there is JNI involved, but if it did, you would have very likely better performance.