[Qgis-developer] Approximate reprojection for vectors

[Marco Hugentobler]

> In any case, the other servers in the benchmark had to fetch the features
> from the same database

Hm, I just see that UMN uses a normal select statement (not a binary cursor as 
QGIS does). Don't know if that could make a difference, probably something for 
me to test (the benchmark infrastructur should still be in place).

Regards,
Marco

Am Montag, 3. Oktober 2011, 08.22:52 schrieb Marco Hugentobler:
> Hi Martin
> 
> > how did you profile? Using callgind, oprofile or directly measuring
> > time?
> 
> It was with callgrind.
> 
> > the time spent within postgres provider while waiting for server to
> > return the features may not be considered.
> 
> That might be a valid point. Is it better to use oprofile for the waiting
> time?
> 
> In any case, the other servers in the benchmark had to fetch the features
> from the same database. So there must be very performance critical
> differences in the other parts of the code. As you might know, QGIS didn't
> really win first price...
> 
> Regards,
> Marco
> 
> Am Sonntag, 2. Oktober 2011, 22.15:55 schrieb Martin Dobias:
> > On Sun, Oct 2, 2011 at 4:33 PM, Marco Hugentobler
> > 
> > <marco.hugentobler at sourcepole.ch> wrote:
> > > I did a lot of profiling for the FOSS4G WMS benchmark (osm data,
> > > reprojected to google crs, complex symbology with a lot of rules). The
> > > pattern was mostly the following:
> > > the rendering itself (QPainter->drawPolyline) was the most time
> > > consuming operation (appr. 50% of rendering time), next was evaluation
> > > in rule based renderer (20% of time), getNextFeature in
> > > PostgresProvider 10%, coordinate transformation 10%.
> > 
> > Marco,
> > 
> > how did you profile? Using callgind, oprofile or directly measuring
> > time? If you used callgrind the results may be significantly skewed:
> > the time spent within postgres provider while waiting for server to
> > return the features may not be considered.
> > 
> > Regards
> > Martin