[Gfoss] Fwd: [Qgis-developer] Benchmarking / optimization

[Paolo Cavallini]

Buone notizie: Radim ha affrontato il problema della velocita' di 
rendering in QGIS.
Ci aspettiamo risultati interessanti.
Saluti.

-------- Messaggio originale --------
Oggetto: 	[Qgis-developer] Benchmarking / optimization
Data: 	Mon, 28 Nov 2011 19:49:24 +0100
Mittente: 	Radim Blazek <radim.blazek at gmail.com>
A: 	qgis-developer <qgis-developer at lists.osgeo.org>



Hi,

because I found QGIS to be terribly slow with larger vectors, I
started to work a bit on rendering optimization. I am still at the
beginning of the work, here are some first findings.

The first step was to get some reliable benchmarks, for which I wrote
a new CLI application, mostly derived from qgis main app (tests/bench,
installed as bin/qgis_bench). I found precise and repeatable CPU time
measurement quite problematic, my observations are summarized in
tests/bench/README [1]. Any idea how to measure time better is
welcome.

Preparing projects for qgis_bench application, I noticed that qgis
renders the same project much slower than qgis_bench. I found that
QgsMapCanvasMap was using by default QPixmap, not QImage, which is 7
times slower! To be precise, QGIS was using QPixmap by default, but in
options GUI was set as default QImage. If "Fix problems with
incorrectly filled polygons" is unchecked (default), QImage is used.
It means that it was sufficient to open options dialog, apply (not
changing anything) and QgsMapCanvasMap started to use QImage.
Obviously, this could not be noticed by developers and advanced users,
because they had used options dialog at least once. Naive users (like
me), who rely on default settings, were using QPixmap. It seems, that
since 2006, all the first-time users (and thus maybe also last-time
users) were experiencing this problem. Is it possible or am I wrong?
Hopefully. Having fixed this problem (fixed in master [2]), the true
optimization may start.

Here are some preliminary benchmark results for master:
http://www.mpasol.it/blazek/qbench/
Y axis is relative rendering time (oldest build time = 100%). X axis
is commiter date for each build. Changes about 1% are not significant
(benchmark inaccuracy). You can place mouse over each point to get
tooltip with more info. It is also possible to zoom in both main chart
and overview.

You may notice, that something bad has probably happened between
8c1c2add and 1d7d1c62 (if there is no bug in my scripts). You can also
see that effect off each change in code depends a lot on data type.

It is important to say, that most of the optimization was already done
by Martin Dobias during GSoC 2010, see his report [3]. Unfortunately
most of them were not yet merged to master. 8c1c2add (see the chart),
is one of those (the only one?) which have been merged, the speed up
is significant.

My next plans are:
1) add more projects (more data types and rendering modes) to my benchmark suite
2) add older builds (as old as possible - where qgis_bench runs with
old libs without recompilation)
3) localize (in time) bigger performance jumps
4) merge optimizations from dev-threading branch (maybe Martin is
going to do that?)

Any comments are welcome.

Radim

[1] https://github.com/qgis/Quantum-GIS/blob/master/tests/bench/README
[2] https://github.com/qgis/Quantum-GIS/commit/6e1d38c13969dab132f877c55c6ccbf9c7f3167b
[3] http://www.qgis.org/wiki/QGIS_on_steroids_GSoC_2010
_______________________________________________
Qgis-developer mailing list
Qgis-developer at lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/qgis-developer

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.gfoss.it/pipermail/gfoss/attachments/20111130/b1d79f79/attachment-0001.html>