GeoDjango：加速GEOS的几何操作

我正在使用GeoDjango + PostGIS开发空间排名应用程序。基本上，它会检索查询边界框内的所有几何，使用我创建的自定义函数计算相似度分数，然后返回具有最高分数的形状。GeoDjango：加速GEOS的几何操作

目前每个查询的往返时间都很慢。正在运行的分析器显示瓶颈来自threadsafe.py，在我的相似度函数内部被GEOSGeometry操作（即相交，联合，包含等）调用。以下是来自单个查询的示例profiler result。看起来GEOSGeometry的线程安全性质是造成性能问题的原因。单独来说，40ms的操作看起来并不是什么大问题，但是因为与查询比较的形状数量通常很大，即〜1000个形状，所以40ms的操作总计达40秒。

因此，我的问题是如何优化功能以最小化周转时间。我的一些初步设想是：

关闭/避免GEOSGeometry的theadsafety检查，因为这些物体是短暂的，不共享任何其他线程。如果可能的话，这将是理想的情况，因为现在花费的大部分时间在threadsafe.py
使用另一个几何非API的几何API。
~~在PostGIS级别而不是对象级别执行空间操作。这会使代码看起来很丑陋。~~ （更新：此选项不起作用单独的SQL查询的开销，使操作更慢。）

什么是你的想法？

来源

2011-07-05 ejel

我试着用'GDALGeometry'附带GeoDjango内置作为替代'GEOSGeometry'。 'GDALGeometry'原来依赖于threadsafe.py，结果执行得更糟。 – ejel

我们转而使用shapely进行地理位置操作。它让我们围绕线程安全问题。

仅供参考，身材匀称使用长，土地增值税，而不是纬度，长的很像GeoDjango内置确实

来源

2011-09-17 23:33:14

由于它的空间操作取决于GEOS，我认为它应该遭受同样的问题。有趣。我会试一试。 – ejel

你有没有设法使用geodjango模型匀称？ – linqu

实际上，threadsafe.py只是将每个调用包装到底层的C函数中。要更好地了解您的瓶颈，请查看cumtime列。请参阅此处以获取列的说明：http://docs.python.org/library/profile.html#module-pstats。

来源

2011-07-05 22:44:28 arghbleargh

你说得对，'threadsafe.py'是C函数的一个包装。我已经仔细检查了配置文件的结果，并且'threadsafe.py'仍然是瓶颈。我的意思是，每次调用空间操作（例如相交，内联合）时都会调用它。实际上在这些操作中花费的时间与线程安全所花的时间相比非常小。这就是为什么我想如果我可以避免使用线程安全，问题就可以解决。 – ejel

看着你的分析器结果，它 – arghbleargh

GeoDjango：加速GEOS的几何操作

回答

相关问题