lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Erick Erickson <erickerick...@gmail.com>
Subject Re: Scale function inefficiency perhaps?
Date Thu, 09 Feb 2012 20:40:41 GMT
Siiiggggh, and I wanted it to be simple. This approach looks doomed;
nested functions apparently don't play nice in this scenario. The test
case that invokes log(val) fails, and digging in a little it looks like the
results of nested functions are in the DocValues array, which makes
the approach below nonsense unless we do some fancy dancing that
would be pretty limited in its utility.

Saved again by someone's diligence with the unit tests <G>.

can anyone confirm?

Thanks,
Erick

On Thu, Feb 9, 2012 at 12:42 PM, Erick Erickson <erickerickson@gmail.com> wrote:
> Mostly, I'm checking to see if I'm hallucinating or not before going forward....
>
> ScaleFloatFunction.getValues iterates through all the values for a
> field in all the documents to find the min and max for a particular
> field it's using. So far, so good. But is this really necessary every
> time it gets called? I don't think these numbers change if the index
> hasn't changed, right? Couldn't the min and max just be cached the
> first time around?
>
> If one were to work up a patch (both 3.x and 4.x I think), I assume
> that reader.getVersion() and min and max could be cached the first
> time around and the list iterated only when the version changes...
>
> The only fly I see in the ointment is that the values would have to be
> shared amongst multiple threads, what's the preferred way to
> synchronize such a thing? It's been a long time since I've been in
> Java synchronization methods....

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org


Mime
View raw message