3

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

目前，每个查询的往返时间非常慢。运行分析器显示瓶颈是由我的相似函数内部threadsafe.py的GEOSGeometry操作（即相交、联合、包含等）调用的。这是来自单个查询的示例分析器结果。看起来线程安全的性质GEOSGeometry是导致性能问题的原因。单独来说，耗时 40 毫秒的操作似乎没什么大不了的，但因为要与查询进行比较的形状数量通常很大，即约 1000 个形状，所以 40 毫秒的操作加起来需要 40 秒。

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

  1. 关闭/避免 的安全性检查GEOSGeometry，因为这些对象是瞬态的，不与任何其他线程共享。如果可能的话，这将是理想的情况，因为现在花费的大部分时间都在threadsafe.py
  2. 使用另一个不安全的几何 API。
  3. 在 PostGIS 级别而不是对象级别执行空间操作。不过，这会使代码看起来很难看。（更新：此选项不起作用。仅 SQL 查询的开销会使操作变得更慢。）

你有什么想法？

4

2 回答 2

1

我们转而使用shapely进行地理操作。它让我们解决了线程安全问题。

仅供参考，匀称地使用 long,lat 而不是 lat,long 就像 GeoDjango 一样

于 2011-09-17T23:33:14.717 回答
0

实际上，threadsafe.py只是包装对底层 C 函数的每个调用。要更好地了解您的瓶颈是什么，请查看该cumtime列。有关列的说明，请参见此处：http: //docs.python.org/library/profile.html#module-pstats。

于 2011-07-05T22:44:28.383 回答