Scott
Leo Galambos wrote:
--Unoptimized index is not a problem for document additions, they take constant time, regardless of the size of the index and regardless of whether the index is optimized or not.IMHO It is not true. It would mean that O(log(n/M))=O(1). (n-number of documents in index, M max number of segments per level). I think that if you are true, we are able to sort an array in O(n) and not in O(nlog n).Searches of unoptimized index take longer than searches of an optimized index.Is there any limitation in Lucene architecture, so that you cannot use multithread algorithm for calculation of hit lists? I think it would boost performance. Otis, thank you for your proof, that Lucene has not it now (you got me :-)). But what about next releases?Then do a search against one, and against the other index, and time it. Then let us know which one is faster and by how much.
OK, I will.
I would like to compare Lucene to another engine. The test would be
precise, because I wanna use it in an academic paper.
Aim of my question was, how could I configure Lucene to get maximum
performance for test. It looks to be pretty hard, because:
- if I do not call optimize(), I can build index at maximum speed, but searches are slow, so it is not configuration for dynamic environment
- if I call optimize() regularly (as real application would do), indexing
is slower and slower when I add more and more documents to the collection
IMHO the second option describes "real environment", so we get:
loop:
K-times indexDoc()
optimize()
end-of-loop
What *K* would I use? 1000, 10000 or 10 or 100? Folks, what *K* do you use in your applications? Thank you.
-g-
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
Brain: Pinky, are you pondering what I�m pondering?
Pinky: I think so, Brain, but calling it a pu-pu platter? Huh, what were they thinking?
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
