I had thought that getCount was supposed to return -1 if it can't fullfull the request efficiently... Or one of the methods was supposed to. I wonder if it is a case where uDig is using the wrong method or if Oracle getCount() is implemented wrong.
Jesse On Aug 29, 2007, at 5:41 AM, Vitali Diatchkov wrote: > > > Just a hint from my mind related to our projects. > > There are situations when 20 layers from Oracle are being rendered. > The data > is spread among the whole territory of Finland and the often > situation is > when there is no data to be rendered at the specified scale ratio > for 17 of > 20 layers. But every renderer not only requests features but also > calls > getCount() method to perform real checking to be sure that there is > no data > to be rendered if empty feature collection has come in the beginning. > getCount() leads to "SELECT count(*) FROM.. WHERE.." and so on in > case of > OracleDataStore - for these 17 layers from 20. Totally we have 3 + > (17 * 2) > requests to the database (if we have 20 layers and only 3 of them > contain > features inside of current Filter). Did not investigate deeply but > there > should be a preference to switch off this getCount() call from > renderer in > case no features were loaded during usual request. > Isn't it the GT renderer calls this stuff, not UDIG wrappers ?... > do not > remember exactly, but anyway - it would be good optimization to > switch off > this call. > > Vitali Diatchkov. > >> -----Original Message----- >> From: [EMAIL PROTECTED] >> [mailto:geotools-devel- >> [EMAIL PROTECTED] On Behalf Of Andrea Aime >> Sent: Tuesday, August 28, 2007 4:54 PM >> To: Geotools-Devel list >> Subject: [Geotools-devel] Various rendering speedups in, feedback >> appreciated >> >> Hi, >> I've just finished committing quite a raft of rendering speedups. >> It's >> not that they'll >> make rendering twice as fast, maybe more on the 30% faster (haven't >> checked >> seriously, in my gs benchs there is also image encoding which is an >> important >> and fixed ratio that my patches haven't touched). >> >> Anyways, I would be interested in hearing from others, especially >> uDig >> users, >> on how the changes are faring. Do you see a visible speedup? Have I >> introduced >> any bug in the optimization process? >> >> I'll keep on working on this, so these patches are just a first >> set of >> changes >> for things that were quite visibile and relatively easy to fix. >> >> Cheers >> Andrea >> >> >> --------------------------------------------------------------------- >> ---- >> This SF.net email is sponsored by: Splunk Inc. >> Still grepping through log files to find problems? Stop. >> Now Search log events and configuration files using AJAX and a >> browser. >> Download your FREE copy of Splunk now >> http://get.splunk.com/ >> _______________________________________________ >> Geotools-devel mailing list >> [email protected] >> https://lists.sourceforge.net/lists/listinfo/geotools-devel > > > ---------------------------------------------------------------------- > --- > This SF.net email is sponsored by: Splunk Inc. > Still grepping through log files to find problems? Stop. > Now Search log events and configuration files using AJAX and a > browser. > Download your FREE copy of Splunk now >> http://get.splunk.com/ > _______________________________________________ > Geotools-devel mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/geotools-devel ------------------------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ _______________________________________________ Geotools-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/geotools-devel
