I think the idea is good but perhaps the interface needs a bit of tweaking.
It might make more sense go reverse the notion and come up with a
"StableFunction" because it seems that a function that returns a static
value (like env) would seem to be the monitory. Perhaps I am wrong though.
Also it would seem that a function implementing the interface simply to
return false would be equivalent to not implementing the interface at all?
So perhaps we could keep the interface strictly a marker interface?
2c.
-Justin
On Wed, Dec 8, 2010 at 3:17 PM, Andrea Aime <[email protected]>wrote:
> Hi,
> for a number of reasons I'd like to be able to analyze a filter and
> optimize out functions when possible.
>
> The main driver behind this is that none of the stores support functions
> natively (they could, but they not) and thus the filters are not fully
> encoded
> down to the database, with much performance detriment.
>
> A typical case is the enviroment function, as soon as it's used the filters
> using it stop being sent to the database, which is of course a performance
> killer. It would be nice to recognize that the function is not using any
> feature attribute, so it can be evaluated at the beginning of the data
> access and optimized out into a literal.
>
> Now, generically speaking the "optimize out" test is just analyzing
> the function arguments and see if there is any usage of the feature
> attributes: if there is none, the function is static, right?
> Err... almost.
> A function such as "random" is not going to return the same value
> twice: that's a purely dynamic function.
>
> A function such as "env" is going to return the same value during
> all the data access, well, at least unless something else changes
> the enviroment map _during_ the data access.
>
> What I would like to have is some sort of DynamicFunction marker
> interface that tells me if a function is dynamic or not. Maybe a
> bit more than just a marker:
>
> interface DynamicFunction {
> /**
> * Returns true if a function is going to return the same
> * value during a data access operation unless
> * someone changes its configuration
> */
> boolean requestStable();
> }
>
> Random would implement that interface and return false,
> env would implement it and return true.
> Stores, in particular JDBC ones, would use a visitor
> that optimizes out all functions not using attribute values
> that are not dynamic, or that are dynamic but request stable.
>
> This would make the usage of env functions better,
> and would solve an issue reported by Mike P. recently
> that the renderer is optimizing out a random() call into
> the symbolizers be optimized out and return the same
> value all over the render.
>
> Opinions?
>
> Cheers
> Andrea
>
> -----------------------------------------------------
> Ing. Andrea Aime
> Senior Software Engineer
>
> GeoSolutions S.A.S.
> Via Poggio alle Viti 1187
> 55054 Massarosa (LU)
> Italy
>
> phone: +39 0584962313
> fax: +39 0584962313
>
> http://www.geo-solutions.it
> http://geo-solutions.blogspot.com/
> http://www.linkedin.com/in/andreaaime
> http://twitter.com/geowolf
>
> -----------------------------------------------------
>
>
> ------------------------------------------------------------------------------
> This SF Dev2Dev email is sponsored by:
>
> WikiLeaks The End of the Free Internet
> http://p.sf.net/sfu/therealnews-com
> _______________________________________________
> Geotools-devel mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/geotools-devel
>
--
Justin Deoliveira
OpenGeo - http://opengeo.org
Enterprise support for open source geospatial.
------------------------------------------------------------------------------
This SF Dev2Dev email is sponsored by:
WikiLeaks The End of the Free Internet
http://p.sf.net/sfu/therealnews-com
_______________________________________________
Geotools-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/geotools-devel
