<div dir="ltr"><div><div>Hi,<br><br></div>I'll take the opportunity of being at the codesprint to try to reduce the amount of WKB usage in the code.<br><br></div><div>For those being at the code sprint, don't hesitate do drop by if you have recommendations or just want to talk.<br></div><div><br></div>CU<br></div><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Jul 19, 2016 at 10:52 AM, Martin Dobias <span dir="ltr"><<a href="mailto:wonder.sk@gmail.com" target="_blank">wonder.sk@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi Patrick<br>
<span class=""><br>
On Tue, Jul 19, 2016 at 9:58 AM, Patrick Valsecchi<br>
<<a href="mailto:patrick.valsecchi@camptocamp.com">patrick.valsecchi@camptocamp.<wbr>com</a>> wrote:<br>
> Hi,<br>
><br>
> I was looking at the perfs of qgis server and I did a small profiling of a<br>
> GetMap on a road layer (linestring) with QGIS configured with defaults. We<br>
> spend a lot of time converting to and from WKB. For example, for rending 67k<br>
> features (3 GetMaps), we do this for each feature:<br>
<br>
</span>Just curious - what did you use for profiling? Release or Debug build?<br>
<span class=""><br>
<br>
> Now, simplifying all the WKB parse/write will gain maybe 10-15% in global<br>
> perfs for this case. But there are maybe reasons for that (memory usage or I<br>
> don't know)?<br>
<br>
</span>For a long time, WKB was the only way to store geometries in QGIS (it<br>
started as PostGIS viewer after all :-). Later GEOS representation was<br>
added and more recently the new geometry classes, so now the<br>
geometries are stored natively in QgsLineStringV2 and others, but<br>
there is still a fair amount of conversions going on in the background<br>
as various parts still use WKB representation. So no reason really for<br>
juggling with WKB apart from historical reasons...<br>
<br>
It would be good to convert the code to use native representation<br>
everywhere and use WKB only for import/export.<br>
<span class=""><br>
<br>
> Why not avoiding simplifying a linestring if its bbox is in the same<br>
> ballpark as the bbox we are rendering? Or maybe this logic: if bboxLS.w /<br>
> nbPoints > pixelW*2 or bboxLS.h / nbPoints > pixelH*2, then we don't do<br>
> simplification. The idea being points are roughly equally spaced in a<br>
> linestring.<br>
<br>
</span>Sounds quite interesting - would be good to get some numbers how much<br>
this would help.<br>
<span class=""><br>
<br>
> Why storing the points as two arrays in QgsLineStringV2 instead of directly<br>
> a QPolygonF?<br>
<br>
</span>Nyall has explained already...<br>
<span class=""><br>
<br>
> I've been focusing only on linestrings for the moment. But I guess the same<br>
> applies to the other types of geometry.<br>
<br>
</span>Yes, but obviously the results from profiling vary quite a lot<br>
depending on provider type and used symbology.<br>
<span class=""><br>
<br>
> I know it's a lot of questions for a single email. But I'm new to this code<br>
> and have no knowledge of its history and the choices/tradeoffs that were<br>
> made.<br>
<br>
</span>No problem!<br>
<br>
Cheers<br>
<span class="HOEnZb"><font color="#888888">Martin<br>
</font></span></blockquote></div><br></div>