将数据从 python 传输到 Windows 中的另一个应用程序的最佳方法是什么?
我正在与 .Net (C++) 团队一起开发一个应用程序,并提供一个 COM 接口来与 python 和其他语言交互。
我们发现通过 COM 推送数据的速度非常慢。
我考虑了几种替代方案:
- 将数据转储到文件并通过
- mmap?
- 直接通过套接字传输数据?
根据您的经验,传递数据的最佳方式是什么?
I'm developing an application with a team in .Net (C++) and provide a COM interface to interact with python and other languages.
What we've found is that pushing data through COM turns out to be pretty slow.
I've considered several alternatives:
- dumping data to a file and sending the file path through com
- Shared Memory via mmap?
- Stream data through a socket directly?
From your experience what's the best way to pass around data?
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(5)
在 Windows 进程间通信机制中,我们使用 Windows 命名管道获得了积极的经验。
使用 Windows 重叠 IO 和 pywin32 中的
win32pipe
模块。您可以在Win32 上的Python 编程一书中了解有关win32 和python 的更多信息。
发送部分只需写入
r'\\.\pipe\mypipe'
。侦听器 (
ovpipe
) 对象保存一个事件句柄,等待可能包含其他事件的消息涉及调用win32event.WaitForMultipleObjects
。这是 python 重叠侦听器类的一部分:
Staying within the Windows interprocess communication mechanisms, we had positive experience using windows named pipes.
Using Windows overlapped IO and the
win32pipe
module from pywin32.You can learn much about win32 and python in the Python Programming On Win32 book.
The sending part simply writes to
r'\\.\pipe\mypipe'
.A listener (
ovpipe
) object holds an event handle, and waiting for a message with possible other events involves callingwin32event.WaitForMultipleObjects
.Here is part of the python overlapped listener class:
XML/JSON 和 Web 服务或直接通过套接字。 它也是独立于语言和平台的,所以如果您决定要在 UNIX 上托管 python 部分,或者如果您想突然使用 Java 或 PHP 或几乎任何其他语言,您可以。
一般来说,像 COM 这样的专有协议/架构带来的限制多于其带来的好处。 这就是开放规范首先出现的原因。
华泰
XML/JSON and a either a Web Service or directly through a socket. It is also language and platform independent so if you decide you want to host the python portion on UNIX you can, or if you want to suddenly use Java or PHP or pretty much any other language you can.
As a general rule proprietary protocols/architectures like COM offer more restrictions than they do benefits. This is why the open specifications appeared in the first place.
HTH
在命名管道上+1,但我还想补充一点,从您的评论来看,您的应用程序似乎非常健谈。 每次进行远程调用时,无论底层传输有多快,整理数据和建立连接的成本都是固定的。 如果将 addpoint(lat, long) 方法更改为 addpoints(point_array) 方法,则可以节省大量开销。 这个想法类似于为什么我们有数据库连接池和http-keep-alive连接。 您实际拨打的电话越少越好。 如果您可以限制对现有 COM 解决方案的调用次数,那么您现有的 COM 解决方案甚至可能就足够好了。
+1 on the named pipes but I would also like to add that from your comments it seems that your application is very chatty. Every time you make a remote call no matter how fast the underlying transport is you have a fixed cost of marshaling the data and making a connection. You can save a huge amount of overhead if you change the addpoint(lat, long) method to a addpoints(point_array) method. The idea is similar to why we have database connection pools and http-keep-alive connections. The less actual calls you make the better. Your existing COM solution may even be good enough if you can just limit the number of calls you make over it.
升级 Python 上 gimel 的答案。
让它与事件一起工作确实很难。
Upgrading answer of gimel on Python.
It was really hard to make it work with events.
为每个替代方案设置测试并进行基准测试应该不会太复杂。 注意到击败上下文敏感的经验数据...:)
哦,如果你这样做,我相信很多人会对结果感兴趣。
It shouldn't be too complicated to set up a test for each of your alternatives and do a benchmark. Noting beats context sensitive empirical data... :)
Oh, and if you do this I'm sure a lot of people would be interested in the results.