<p dir="ltr">Out of curiosity, how long of a delay do you estimate would be needed to fix things? 4 weeks, 8 weeks? </p>
<div class="gmail_quote">On 23 Jun 2015 09:09, "Nyall Dawson" <<a href="mailto:nyall.dawson@gmail.com">nyall.dawson@gmail.com</a>> wrote:<br type="attribution"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><p dir="ltr">Hi all,</p>
<p dir="ltr">Unfortunately, we've become aware of a serious performance regression caused by the new geometry engine. Basically, the situation is that for all geometry operations which rely on geos (think buffers, splits, spatial relation operations such as intersects and within,... ) the geometry now needs to be converted into a geos representation with *every* operation. In the old geometry engine this conversion was done once, and the result stored so that follow up operations would not need to recalculate it. This potentially has huge impacts on the performance of common tasks such as selecting all features which intersect a geometry.</p>
<p dir="ltr">I've had a look, and unfortunately it's not trivial to fix this. I think the correct solution to this is to:</p>
<p dir="ltr">- make QgsGeometryEngine accept and return QgsGeometry containers, not QgsAbstractGeometryV2<br>
- store the generated geos representation of geometries within QgsGeometryPrivate inside the QgsGeometry container. This way it will be reusable between different geometry operations, and shared when QgsGeometry objects are copied. This will also have the benefit that if a geometry is prepared using geos then subsequent geos operations performed on that QgsGeometry and its shared copies will be much faster.<br>
- make QgsGeometry a friend class of QgsGeo, so that it can access QgsGeometryPrivate to retrieve or set the geos representation of the geometry as required</p>
<p dir="ltr">An alternative (short term) solution would be to just cache the geos representation when geometry operations are called through the older QgsGeometry modification/relationship operations. This would be easier, but means that the API of QgsGeometryEngine will be stuck with the current design, and we won't be able to properly fix this until breaking the api for 3.0.</p>
<p dir="ltr">Either way, I doubt this can be addressed within the remaining 3 days we have until release. Should we delay to address this? Release with the regression? Or am I missing something and there's an easier solution we could implement? Or even possibly this additional cost of recalculating the geos representation is trivial and can be ignored (maybe someone could test this with a little repeated intersection script)?</p>
<p dir="ltr">Thoughts?</p>
<p dir="ltr">Nyall<br>
</p>
<br>_______________________________________________<br>
Qgis-developer mailing list<br>
<a href="mailto:Qgis-developer@lists.osgeo.org">Qgis-developer@lists.osgeo.org</a><br>
<a href="http://lists.osgeo.org/mailman/listinfo/qgis-developer" rel="noreferrer" target="_blank">http://lists.osgeo.org/mailman/listinfo/qgis-developer</a><br></blockquote></div>