[Qgis-developer] Perfs: a lot of WKB conversions

[Martin Dobias]

Hi Patrick

On Tue, Jul 19, 2016 at 9:58 AM, Patrick Valsecchi
<patrick.valsecchi at camptocamp.com> wrote:
> Hi,
>
> I was looking at the perfs of qgis server and I did a small profiling of a
> GetMap on a road layer (linestring) with QGIS configured with defaults. We
> spend a lot of time converting to and from WKB. For example, for rending 67k
> features (3 GetMaps), we do this for each feature:

Just curious - what did you use for profiling? Release or Debug build?


> Now, simplifying all the WKB parse/write will gain maybe 10-15% in global
> perfs for this case. But there are maybe reasons for that (memory usage or I
> don't know)?

For a long time, WKB was the only way to store geometries in QGIS (it
started as PostGIS viewer after all :-). Later GEOS representation was
added and more recently the new geometry classes, so now the
geometries are stored natively in QgsLineStringV2 and others, but
there is still a fair amount of conversions going on in the background
as various parts still use WKB representation. So no reason really for
juggling with WKB apart from historical reasons...

It would be good to convert the code to use native representation
everywhere and use WKB only for import/export.


> Why not avoiding simplifying a linestring if its bbox is in the same
> ballpark as the bbox we are rendering? Or maybe this logic: if bboxLS.w /
> nbPoints > pixelW*2 or bboxLS.h / nbPoints > pixelH*2, then we don't do
> simplification. The idea being points are roughly equally spaced in a
> linestring.

Sounds quite interesting - would be good to get some numbers how much
this would help.


> Why storing the points as two arrays in QgsLineStringV2 instead of directly
> a QPolygonF?

Nyall has explained already...


> I've been focusing only on linestrings for the moment. But I guess the same
> applies to the other types of geometry.

Yes, but obviously the results from profiling vary quite a lot
depending on provider type and used symbology.


> I know it's a lot of questions for a single email. But I'm new to this code
> and have no knowledge of its history and the choices/tradeoffs that were
> made.

No problem!

Cheers
Martin