[Qgis-developer] Potentially serious performance regression in new geometry - should 2.10 be delayed?

[Mathieu Pellerin]

Out of curiosity, how long of a delay do you estimate would be needed to
fix things? 4 weeks, 8 weeks?
On 23 Jun 2015 09:09, "Nyall Dawson" <nyall.dawson at gmail.com> wrote:

> Hi all,
>
> 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.
>
> I've had a look, and unfortunately it's not trivial to fix this. I think
> the correct solution to this is to:
>
> - make QgsGeometryEngine accept and return QgsGeometry containers, not
> QgsAbstractGeometryV2
> - 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.
> - 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
>
> 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.
>
> 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)?
>
> Thoughts?
>
> Nyall
>
> _______________________________________________
> 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.osgeo.org/pipermail/qgis-developer/attachments/20150623/4772710d/attachment-0001.html>