[ https://issues.apache.org/jira/browse/LUCENE-4574?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13505650#comment-13505650 ]
David Smiley commented on LUCENE-4574: -------------------------------------- Rob, FunctionQuery$AllScorer.score() is pretty simple and innocent enough so perhaps that is not the right place to add the cache either. Some ValueSources might have a trivial value e.g. a constant, some might be expensive. [~yo...@apache.org], your first comment was: bq. FunctionValues isn't the right place to solve this... that would cause caching/checking at every level of a function. Do you mean it's wrong for a custom ValueSource I wrote to have its FunctionValues, which I know to be expensive because I wrote it, cache its previous value? That's hard to believe so perhaps you don't mean that. Here's a proposal. Add a ValueSource method boolean nonTrivial(), defaulting to true to be safe but overriding in many subclasses to use false as appropriate. Then, FunctionQuery$AllScorer's constructor (called only per-segment) can check and wrap in a to-be-developed FunctionValues caching wrapper for floatVal(). Unlike my previous proposal in the collector, this proposal targets cases that self-declare themselves to have non-trivial implementations and so are worth caching. > FunctionQuery ValueSource value computed twice per document > ----------------------------------------------------------- > > Key: LUCENE-4574 > URL: https://issues.apache.org/jira/browse/LUCENE-4574 > Project: Lucene - Core > Issue Type: Bug > Components: core/search > Affects Versions: 4.0, 4.1 > Reporter: David Smiley > Attachments: LUCENE-4574.patch, Test_for_LUCENE-4574.patch > > > I was working on a custom ValueSource and did some basic profiling and > debugging to see if it was being used optimally. To my surprise, the value > was being fetched twice per document in a row. This computation isn't > exactly cheap to calculate so this is a big problem. I was able to > work-around this problem trivially on my end by caching the last value with > corresponding docid in my FunctionValues implementation. > Here is an excerpt of the code path to the first execution: > {noformat} > at > org.apache.lucene.queries.function.docvalues.DoubleDocValues.floatVal(DoubleDocValues.java:48) > at > org.apache.lucene.queries.function.FunctionQuery$AllScorer.score(FunctionQuery.java:153) > at > org.apache.lucene.search.TopFieldCollector$OneComparatorScoringMaxScoreCollector.collect(TopFieldCollector.java:291) > at org.apache.lucene.search.Scorer.score(Scorer.java:62) > at > org.apache.lucene.search.IndexSearcher.search(IndexSearcher.java:588) > at > org.apache.lucene.search.IndexSearcher.search(IndexSearcher.java:280) > {noformat} > And here is the 2nd call: > {noformat} > at > org.apache.lucene.queries.function.docvalues.DoubleDocValues.floatVal(DoubleDocValues.java:48) > at > org.apache.lucene.queries.function.FunctionQuery$AllScorer.score(FunctionQuery.java:153) > at > org.apache.lucene.search.ScoreCachingWrappingScorer.score(ScoreCachingWrappingScorer.java:56) > at > org.apache.lucene.search.FieldComparator$RelevanceComparator.copy(FieldComparator.java:951) > at > org.apache.lucene.search.TopFieldCollector$OneComparatorScoringMaxScoreCollector.collect(TopFieldCollector.java:312) > at org.apache.lucene.search.Scorer.score(Scorer.java:62) > at > org.apache.lucene.search.IndexSearcher.search(IndexSearcher.java:588) > at > org.apache.lucene.search.IndexSearcher.search(IndexSearcher.java:280) > {noformat} > The 2nd call appears to use some score caching mechanism, which is all well > and good, but that same mechanism wasn't used in the first call so there's no > cached value to retrieve. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org