我正在做一个正在试验 boost python 的项目。在研究如何组织我的 python 界面时,我遇到了一条评论,声称 boost python 存在性能问题。它的性能有什么实际问题吗?
在这种情况下,我正在处理一个大型项目,我们希望将其中的一些暴露给 python。我发现 boost python 可以很容易地公开我已经拥有的类。所以我宁愿坚持使用 boost python 的暴露类的方法,因为它很简单。除非有人有一个同样易于使用和高性能的替代方案。
我正在做一个正在试验 boost python 的项目。在研究如何组织我的 python 界面时,我遇到了一条评论,声称 boost python 存在性能问题。它的性能有什么实际问题吗?
在这种情况下,我正在处理一个大型项目,我们希望将其中的一些暴露给 python。我发现 boost python 可以很容易地公开我已经拥有的类。所以我宁愿坚持使用 boost python 的暴露类的方法,因为它很简单。除非有人有一个同样易于使用和高性能的替代方案。
如果您的用例需要在紧密循环中在 Python 和 C++ 之间来回调用大量调用,那么 Boost.Python 可能是一个性能问题,至少相对于直接使用 Python C-API 的手动包装器而言。很难猜测它是否会比类似用户友好的东西(如 SWIG)更糟糕。
但最大的性能问题是您是否可以避免这种来回的来回——无论您使用什么库或包装工具,一个可以避免反复跨越 C++/Python 障碍的 API 通常总是比这样做的 API 性能更好。大多数情况下,这意味着将循环从 Python 移至 C++,并避免 Python 回调,尤其是在这些循环中避免 Python 到 C++ 的类型转换。
我们正在使用 boost::python 将一个大型计算机视觉库集成到一个高度可配置的软件包中,供其他领域的研究人员使用。我们没有遇到任何疑虑或问题。但是,我们最近没有进行任何比较测试。