Re: [CLucene-dev] CLucene's future

[Alan W. <ala...@go...>]

Hi Itamar,

Thanks for taking time to look at Lucene++

The intention behind Lucene++ has always been to closely reflect the java
lucene code with a view to being able to keep up with the pace of development.

The good news with this approach means that I can quickly integrate bug
fix releases - in fact it only took a matter of days to integrate changes from
3.0.0 -> ... -> 3.0.3.

The disadvantages with this approach are that the library is quite large
(~10MB) because of the close modelling of the java code (there's a lot of it!).
Also, I make use of boost::shared_ptr to represent pointers - this means
complex memory handling is very much reduced, at the expense of
performance.

What I'm currently working on is taking Ben's changes an merging them in
the master (http://github.com/luceneplusplus/LucenePlusPlus), this should:

1) Reduce the number of symbols exported - reducing the link time and
library size

2) Add support for CMake.

Looking forward, there's a new fairly substantial feature release of java lucene
(3.1) that will require porting.  I also look forward to working with you (and
anyone else!) in order to continually improve Lucene++/CLucene performance.

cheers,
Alan.


On 31 March 2011 01:25, Itamar Syn-Hershko <it...@co...> wrote:
>
> Hi all,
>
>
> CLucene has grown quite nicely the last few years, but yet we were
> unable to keep up with the high pace of Java Lucene's. Our goal has
> always been to have Lucene on steroids, and have it more maintainable
> and up to speed with Java Lucene.
>
>
> As Ben mentioned here last week, now there's Lucene++ written by Alan
> Wright which is easier to maintain, and therefore it allows to keep up
> with Java Lucene more easily - not to mention making bindings and
> porting of contribs more easily. However, Lucene++ is currently
> significantly heavier than CLucene, and is having several downsides we
> currently don't have (or don't want to have) in CLucene.
>
>
> Ben and I have decided to try and modify Lucene++ so it is lighter and
> works faster, and when we are done we plan on making the result the main
> branch of CLucene. This should allow us to concentrate on performance
> tuning, and on making more tools accessible to the community. Being more
> recent and with bindings to other languages should make the project more
> known and the community bigger.
>
>
> However, that means serious API change, and having a larger and heavier
> library, as mentioned in a previous thread. It also means we will not be
> able to support the 2_3_2 branch for long. The main downside here is if
> someone finds the current implementation perfect and is afraid of having
> a heavier library.
>
>
> We'd appreciate your opinions on the matter, or any help pulling this off.
>
>
> Itamar.
>
>
> ------------------------------------------------------------------------------
> Create and publish websites with WebMatrix
> Use the most popular FREE web apps or write code yourself;
> WebMatrix provides all the features you need to develop and
> publish your website. http://p.sf.net/sfu/ms-webmatrix-sf
> _______________________________________________
> CLucene-developers mailing list
> CLu...@li...
> https://lists.sourceforge.net/lists/listinfo/clucene-developers