Personally I am willing to trade some performance for always being up to date with the latest Java releases and also being able to use other Java code. Although as far as I have seen most people say it's at the same speed or even slightly faster than the .NET version.
I personally would be more likely to contribute to IKVM if there are any issues since it would also benefit other Java code I use like TIKA. I wonder if anybody has ever tried Lucene with IKVM in a heavy load production environment. I use it in a one thread per index desktop app and wouldn't notice if there were any issues under heavy load. On Wed, Jan 26, 2011 at 14:01, Troy Howard <[email protected]> wrote: > I'm on the fence about IKVM. > > It has some significant benefits and some significant drawbacks: > > Benefits: > - Allows us to get to a "commoditized" line-by-line .NET DLL in the > fastest and easiest manner. No porting. > - Reasonable performance profile > - Well tested Java environment equivalence > > Drawbacks: > - Blackbox, can't improve on it or tweak behaviour. If there are bugs > or other issues, related to IKVM (ie thread safety, memory handling, > etc) we can't fix those without dropping IKVM as our solution. > - Adds an additional dependency > - May not be the best possible performance profile. As DIGY said, it's > roughly equivalent, but that doesn't mean that current Lucene.Net is > fully optimized for .NET. In fact, it has been proven not to be by > folks who have made custom builds/forks, realizing significant > speedups using generics, etc.. > > Also, that's a significant change in the library, which will introduce > breaking API changes, and require us to beef up the unit tests to > ensure that concerns like thread safety continue to behave as > expected. > > Thanks, > Troy > > On Wed, Jan 26, 2011 at 10:39 AM, Hans Merkl <[email protected]> wrote: > > A .NET wrapper around the IKVM classes may be a good idea. > > > > I like the idea that IKVM would also allow use of tons of other useful > > Java/Lucene code that's out there. There are some filters and analyzers > in > > Java that might be very useful for my work. That's not really possible > with > > the line-by-line port. It may be possible with Sharpen though. > > > > On Wed, Jan 26, 2011 at 13:04, Digy <[email protected]> wrote: > > > >> In theory you can use ikvmc to compile the Java source files into a .NET > >> DLL > >> that references some IKVM DLLs and an ikmvc'ed version of OpenJDK's > >> classlib. After that it is a plain .NET DLL and one could write a .NET > >> centric API using that DLL. > >> > >> > >> > >> I haven't really tried it on anything serious and it may become tricky > if > >> reflection gets involved. And there is some layer of indirection you > >> wouldn't have by a line by line translation that may lead to decreased > >> performance. I'd be game to try it out, though. > >> > >> ---- > >> > >> > >> > >> A few yers ago, I tried IKVM with ~300M (200-300 bytes) documents. It > was > >> surprisingly as fast as Lucene.Net. That may mean that we should fix > >> something in the code. > >> > >> > >> > >> Reflection is another nice thing in IKVM. You can even load and execute > >> Java > >> classes J > >> > >> > >> > >> DIGY > >> > >> > >> > >> > > >
