> > Be careful: checkAbort needs to be called "fairly" frequently so > IndexWriter.close(false) doesn't take too long. >
Of course - I meant check up front if checkAbort != null, and then always call work() if it's not null. But I also agree that a dummy impl is the better approach, since it's not a common case that checkAbort == null. If there are no deletions, it's just a null pointer check, right? > Well ... one null pointer check here, one null pointer check there and at some point you will see a difference. My point wasn't the null pointer check itself, but the pointer check for *every* document in mergeFields() and *every* document in mergeVectors(). So regardless if there are deletions or not, we do a pointer check (actually a boolean check), and for every document. For a very large segment, I believe it will amount to something. Overall I don't think it will improve the performance significantly (although fixing this in many places can have a certain affect on performance), but it will clean up the code, and these *redundant* checks won't stand out (after all, during the iteration the reader won't suddenly have or not have deletions ...). So should I open an issue? Shai On Tue, Jun 9, 2009 at 7:29 PM, Earwin Burrfoot <ear...@gmail.com> wrote: > > Actually: I think we should also change IndexReader.document to not > > check if it's deleted? (Renaming it to something like rawDocument(), > > storedDocument(), something, in the process, and deprecating the old > > one). > Yup. After all the most common use-case is to load a document after > finding it in one or another way. Pretty hard to come up with id of a > deleted document. > > -- > Kirill Zakharenko/Кирилл Захаренко (ear...@gmail.com) > Home / Mobile: +7 (495) 683-567-4 / +7 (903) 5-888-423 > ICQ: 104465785 > > --------------------------------------------------------------------- > To unsubscribe, e-mail: java-dev-unsubscr...@lucene.apache.org > For additional commands, e-mail: java-dev-h...@lucene.apache.org > >
