Don't do that <G>.... Let's back up a second and ask why in the world you want to do this, what's the use-case you're satisfying? Because spinning through all the results and getting information from the underlying documents is inherently expensive since, as Sanne says, you're doing disk seeks. Most Lucene apps only do this for a few documents (think pages) of a search.
So understanding why you want to do this may allow some alternatives to be suggested. Best Erick On Mon, Mar 21, 2011 at 2:16 PM, Brian Hurt <bhur...@gmail.com> wrote: > I'm having a problem with the performance of lazily-loaded fields with > lucene. The basic structure of the code is that I get a set of documents > back from a query, then iterate through them, reading most fields to collect > fragments. This is taking an excessively long amount of time- mostly in my > call to getField on the document. Each such call takes milliseconds, > meaning a query that even returns only a few dozen items takes me hundreds > of milliseconds to process, which is causing problems elsewhere. So the > question I have is if there is some way I can optimize the loading of > fields? I am calling the doc function on the index search with a null > FieldSelector, but this does not seem to reduce the cost of getting fields > (indeed, it seems to slow down the whole query processing by a significant > factor). Is there any help anyone can give me? > > Thanks. > > Brian > --------------------------------------------------------------------- To unsubscribe, e-mail: java-user-unsubscr...@lucene.apache.org For additional commands, e-mail: java-user-h...@lucene.apache.org
