lucenenet-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Digy" <digyd...@gmail.com>
Subject RE: Stefan's Newbie Questions (was Re: Proposal Status, Initial Committors List, Contributors List)
Date Wed, 26 Jan 2011 20:55:07 GMT
Although TIKA is a very good project, I've never needed it in windows
environment. Using Ifilter interface solves most(if not all) of the problems
related with converting a document to text.

DIGY


-----Original Message-----
From: Hans Merkl [mailto:hm@hmerkl.com] 
Sent: Wednesday, January 26, 2011 10: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 <thoward37@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 <hm@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 <digydigy@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
> >>
> >>
> >>
> >>
> >
>


Mime
View raw message