Hi Radim Did you measure with callgrind or any other tool. Maybe this explains the difference (as Martin pointed out).
> Could it be that a different paint device is doing the difference? But > when rendering on screen, we are using QImage or QImage anyway and in > that case graphics card's power is not used, is it? Both QGIS server and desktop use QImage (except if you have 'fix problem with incorrectly filled polygons' checked. In this case QPixmap is used). I'm not sure how important the graphics card is for 2D rendering. In the wms benchmark, the servers with AGG rendering engine performed best. And afaik AGG is pure software rendering. I'm however not a computer graphics guru, so maybe someone with more insight could correct / comment here. > In my case, with Shapefile, QgsOgrProvider::getNextFeature is taking > over 50% and most of it is strcasecmp in GDAL (probably because of > unnecessary calls from QGIS (for Frank, if you are reading this)). I > believe that it can be optimised, I'll look at it. I remember in last years wms benchmark, we were completely out of the game at the shapefile test. Could well be there is some room for improvements here. Regards, Marco Am Dienstag, 4. Oktober 2011, 09.14:37 schrieb Radim Blazek: > On Sun, Oct 2, 2011 at 9:33 PM, Marco Hugentobler > <marco.hugentob...@sourcepole.ch> > 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), > > I always thought that Qt4 rendering engine is quite efficient. Also in > my case (I am testing with Shapefile) QPainte::drawPolyline takes only > 0.05% (!!!), it seems that I am looking on some wrong results comaring > to your 50%, but I cannot find what am I doing wrong. > Could it be that a different paint device is doing the difference? But > when rendering on screen, we are using QImage or QImage anyway and in > that case graphics card's power is not used, is it? > > > next was evaluation in rule based > > renderer (20% of time), getNextFeature in PostgresProvider 10%, > > coordinate transformation 10%. > > In my case, with Shapefile, QgsOgrProvider::getNextFeature is taking > over 50% and most of it is strcasecmp in GDAL (probably because of > unnecessary calls from QGIS (for Frank, if you are reading this)). I > believe that it can be optimised, I'll look at it. > > Radim -- Dr. Marco Hugentobler Sourcepole - Linux & Open Source Solutions Churerstrasse 22, CH-8808 Pfäffikon SZ, Switzerland marco.hugentob...@sourcepole.ch http://www.sourcepole.ch Technical Advisor QGIS Project Steering Committee _______________________________________________ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer