lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Bernhard Messer <>
Subject Re: compound files question/patch
Date Sat, 13 Nov 2004 11:47:57 GMT

your idea sounds reasonable to me. Could you add a new patch to bugzilla 
and attach the diff to it. This ensures that the patch didn't get lost 
within the thousands of emails and if there is some time we will have a 
look on it.

thanks in advance

Kevin Oliver schrieb:

>While investigating some performance issues during queries, I stumbled upon a small issue
in SegmentReader in regards to compound files. Specifically, the openNorms() method takes
in the directory to use, but then has its own logic as to use that directory or the directory
from its base class (IndexReader). When an index has many field infos, we have about 30, this
logic about checking for files existing adds a significant overhead. Although this is a small
inefficiency in a normal file system, our file system is mounted over nfs, and this check
is relatively expensive. 
>The rest of the class doesn't do this sort of check for other files. By changing this
code to work like the rest of the methods in the class (i.e. just using the passed in directory),
things are a good bit quicker on my end. I don't see any issues with this patch. If people
prefer, I can put this in bugzilla.
><         // look first for re-written file, then in compound format
>>        norms.put(, new Norm(cfsDir.openFile(fileName), fi.number));
><         Directory d = directory().fileExists(fileName) ? directory() : cfsDir;
><         norms.put(, new Norm(d.openFile(fileName), fi.number));
>To unsubscribe, e-mail:
>For additional commands, e-mail:

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message