[jira] Created: (LUCENE-1344) Make the Lucene jar an OSGi bundle

Make the Lucene jar an OSGi bundle -- Key: LUCENE-1344 URL: https://issues.apache.org/jira/browse/LUCENE-1344 Project: Lucene - Java Issue Type: Improvement Components: Build Reporter: Ni

[jira] Updated: (LUCENE-1344) Make the Lucene jar an OSGi bundle

[ https://issues.apache.org/jira/browse/LUCENE-1344?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Nicolas Lalevée updated LUCENE-1344: Attachment: LUCENE-1344-r679133.patch Here is a patch against trunk. The patch on common-

performance optimizations

I hope this doesn't offend anyone, but I think this is an excellent article that the Lucene development team might find helpful. I have often been dismayed at complex code being written to achieve "negligible" performance improvements. Most often, a micro benchmark is used to justify the ch

Re: performance optimizations

Making well reasoned arguments about specific patches would be helpful. Also, the complexity vs speed trade-offs are different for core library like Lucene where performance is one of the primary features. -Yonik On Wed, Jul 23, 2008 at 4:01 PM, robert engels <[EMAIL PROTECTED]> wrote: > I hope t

Re: performance optimizations

sure, nice article, big Ohhh notation should be addressed first, but try running Analyzers before Mike added char[] and compare try Indexing with some older versions, basically nothing significantly changed from the algorithmic point of view Doug set years ago, all that happened there is just r

Re: performance optimizations

True to an extent, but you may have missed the authors point - by coding complex bit twiddling routines, you often mess up the optimizer in the JIT (and others), possibly preventing better performance later (as the JIT continually improves). Worse, the code is being changed in a very haphaz

Re: performance optimizations

and just one more for arguments sake, in Lucene "obscure bit twiddling" is "the great deal", have a look at all recent / old work on inverted index design, p4delta, rank9/16 ... it is nothing more nor less than "obscure bit twiddling" - Original Message > From: eks dev <[EMAIL

Re: performance optimizations

> > It also seems that many more "obscure, index corruption" type bugs > have crept in as the pursuit of performance has taken place, whereas > the 1.9 and prior code was very stable. come on, this bug you point to is clear jvm bug that Lucene community contributed back to Sun... on the ot

Re: performance optimizations

The bug/issue I was referring to is the pread/multiple file descriptors. This is a clear issue in the JVM, and has been for a long time. Count the hours spent of discussing/devising/debugging/implementing this issue, instead of just having it fixed in the JVM. Not worth the work IMO (and

[jira] Created: (LUCENE-1345) Allow Filter as clause to BooleanQuery

Allow Filter as clause to BooleanQuery -- Key: LUCENE-1345 URL: https://issues.apache.org/jira/browse/LUCENE-1345 Project: Lucene - Java Issue Type: Improvement Components: Search Rep

[jira] Updated: (LUCENE-1345) Allow Filter as clause to BooleanQuery

[ https://issues.apache.org/jira/browse/LUCENE-1345?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Paul Elschot updated LUCENE-1345: - Attachment: LUCENE-1345.patch A first half attempt, it still leaves a few compile errors. This

[jira] Commented: (LUCENE-1336) Distributed Lucene using Hadoop RPC based RMI with dynamic classloading

[ https://issues.apache.org/jira/browse/LUCENE-1336?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12616323#action_12616323 ] Jason Rutherglen commented on LUCENE-1336: -- The dynamic classloading mechanism as