As a consumer (and I think that most consumers would agree), I'd have to
disagree STRONGLY on trading off performance for ease of conversion.
Lucene and Lucene.NET is predicated on performance, compromising that, IMO,
runs contrary to the core principals of Lucene.
- Nick
-----Original Message-----
From: Hans Merkl [mailto:h...@hmerkl.com]
Sent: Wednesday, January 26, 2011 3:18 PM
To: lucene-net-dev@lucene.apache.org
Subject: Re: Stefan's Newbie Questions (was Re: Proposal Status, Initial
Committors List, Contributors List)
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 <thowar...@gmail.com> 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 <h...@hmerkl.com> 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 <digyd...@gmail.com> 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
> >>
> >>
> >>
> >>
> >
>
