On Sat, Nov 15, 2003 at 01:50:01PM -0700, Erik Hatcher wrote: > On Saturday, November 15, 2003, at 11:59 AM, Dror Matalon wrote: > >>If this date range is pretty static, you could (in Lucene's CVS > >>codebase) wrap the DateFilter with a CachingWrappingFilter. Or you > >>could construct a long-lived instance of an equivalent QueryFilter and > >>reuse it across multiple queries. You would likely see dramatic > >>differences using either of these approaches. > >> > > > >I did some timing tests and it looks like time is spent in the actual > >query rather than in creating the filter object. This seems to > >contradict your suggestion here, or am I misunderstanding how filters > >work? > > Creating the filter object is not expensive... it's when it's used in > the IndexSearcher.search method (i.e. when the bitset method is called) > that the expense of term enumeration occurs. DateFilter does not cache > it's bitset though, so if you are reusing the same DateFilter over and > over you will incur that expense every time. CachingWrappingFilter, > though, will cache the enumerated bitset and using the same instance > again will not incur that expense of enumerating terms. > > Make sense? So maybe the timing tests you were doing were timing the > DateFilter as well.
Yes, it makes sense now. And caching will help us because we have a limited number of date ranges that we offer. So we'll cache these using CachingWrappingFilter and we should get good response time. Dror > > Erik > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > -- Dror Matalon Zapatec Inc 1700 MLK Way Berkeley, CA 94709 http://www.fastbuzz.com http://www.zapatec.com --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
