Jody Garnett ha scritto: > aaime wrote: >> Hi, >> >> I'm wondering, since our AttributeExpressionImpl code is still >> very slow due to pure dynamic evaluation of Class.isInstance >> and Class.isAssignamentFrom (which, added, consume more than the >> drawing time itself), I'm wondering if we could put to good >> use the Janino library. >> > Andrea can we do any kind of "prescan" of the Expression? Ie making sure > all the decisions are > made once at the start of rendering - and then flying through expression > evaluation at runtime?
Yes, we could. But that would add another level of care in order to make things perform. I mean, we should be "average" out of the box, that is, not suck from a performance point of view, nor be too hard to use. > Another way to solve this problem would be to select different Filter > implementation (ie > configure the FactoryFinder) once before use. This would put us back > where we were > before in that the implementation would be "tuned" to FeatureType. At a > programming > level we could have something like the JDBC predefined statements. Or a > utility class > that you passed in your FeatureType and your "generic" Filter; and it > gave you back one > that had been optimized/simplified/defined. The latter is the one I like the most. It would be something that is provided with some insurance that the data structures are regular, that is, you don't mix features and beans in the same collection, or simple and complex features. Wondering... couldn't the AttributeExpressionImpl simply assume the accessor and converter are going to be always the same, and try to recompute another only when the cached one fails? Wouldn't it be even easier? >> Here is an article that explains how >> to build classes at run time using that library: >> http://today.java.net/pub/a/today/2007/02/15/tackling-performance-problems-with-janino.html >> >> >> > I like it :-) Exactly the kind of crazy that will make debugging difficult. Hum, indeed this is true. Very concerned about this, in fact. > The biggest draw for me with your idea Andrea is this ... > Filter/Expression is a small scripting language. Actually treating > it as such (compile it into a Java class or use some of the Java 6 > scripting wonderment) clean up our thinking on the matter. > (If you paid attention to Mattias comments this week he was horrified > that Filter / Expression were not normal classes > that could be extended ... we presented them as elements for a scripting > language training people would be easier). I hear you. Your debugging concerns makes me think a lot. At the same time, moving most of the filter and expression handling in an external language is appealing, since we could move away a sizable amount of code and maintenance effort, and gain in flexibility too (every scripting language is more powerful than what we have now afaik). Cheers Andrea ------------------------------------------------------------------------- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV _______________________________________________ Geotools-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/geotools-devel
