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 <ita...@code972.com> 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 > CLucene-developers@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/clucene-developers ------------------------------------------------------------------------------ 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 CLucene-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/clucene-developers
