Python-then-profile-then-C 设计模式的最佳实践？
一种流行的软件开发模式似乎是：
- 用 Python 思考逻辑和算法。
- 进行分析以找出缓慢的部分。
- 将其替换为 C.Ship
- 代码，这是高级和快速之间的最佳权衡。
我说受欢迎只是因为我看到人们谈论它是一个好主意。
但有没有真正使用过这种方法的大型项目呢？最好是免费软件项目，这样我就可以看看他们是如何做到的——也许还能学到一些最佳实践。
A popular software development pattern seems to be:
- Thrash out the logic and algorithms in Python.
- Profile to find out where the slow bits are.
- Replace those with C.
- Ship code that is the best trade-off between high-level and speedy.
I say popular simply because I've seen people talk about it as being a great idea.
But are there any large projects that have actually used this method? Preferably Free software projects so I can have a look and see how they did it - and maybe learn some best practices.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（4）
人们实现发展的方式有很多种。
有时人们按照你的三个步骤发现慢是由于外部环境造成的，因此将Python重写为C并不能解决问题。这种缓慢有时可以在系统端解决，有时可以通过应用不同的算法在 Python 中解决。例如，您可以缓存网络响应，这样您就不必每次都访问网络，或者在 SQL 中，您可以将工作卸载到在服务器上运行的“存储过程”中，并减少结果集的大小。一般来说，当您确实需要用 C 重写某些内容时，要做的第一件事就是查找预先存在的库，然后创建一个 Python 包装器（如果尚不存在）。在您之前，很多人都已经走过了这些道路。
通常，第一步是研究应用程序架构，怀疑某些区域可能存在性能问题，然后选择一个 C 库（可能已经为 Python 封装）并使用它。然后，第 2 步只是确认不存在需要解决的重大性能问题。
我想说，对于一个拥有一个或多个经验丰富的开发人员的团队来说，最好从一开始就尝试预测性能瓶颈并使用预先存在的模块来缓解它们。如果您是 python 初学者，那么您的 3 步过程是完全有效的，即开始构建和测试代码，知道有一个探查器以及快速 C 模块（如果您需要）的可能性。然后还有 psyco，以及用于将应用程序冻结为二进制可执行文件的各种工具。
如果您知道需要使用一些 C 或 C++ 模块，另一种方法是从头开始用 C 编写应用程序，但嵌入 Python 来完成大部分工作。这对于经验丰富的 C 或 C++ 开发人员来说非常有效，因为他们对 C 中乏味的代码类型有一个粗略的了解。
There are lots of different ways that people approach development.
Sometimes people follow your three steps and discover that the slow bits are due to the external environment, therefore rewriting Python into C does not address the problem. That type of slowness can sometimes be solved on the system side, and sometimes it can be solved in Python by applying a different algorithm. For instance you can cache network responses so that you don't have to go to the network every time, or in SQL you can offload work into `stored procedures which run on the server and reduce the size of the result set. Generally, when you do have something that needs to be rewritten in C, the first thing to do is to look for a pre-existing library and just create a Python wrapper, if one does not already exist. Lots of people have been down these paths before you.
Often step 1 is to thrash out the application architecture, suspect that there may be a performance issue in some area, then choose a C library (perhaps already wrapped for Python) and use that. Then step 2 simply confirms that there are no really big performance issues that need to be addressed.
I would say that it is better for a team with one or more experienced developers to attempt to predict performance bottlenecks and mitigate them with pre-existing modules right from the beginning. If you are a beginner with python, then your 3-step process is perfectly valid, i.e. get into building and testing code, knowing that there is a profiler and the possibility of fast C modules if you need it. And then there is psyco, and the various tools for freezing an application into a binary executable.
An alternative approach to this, if you know that you will need to use some C or C++ modules, is to start from scratch writing the application in C but embedding Python to do most of the work. This works well for experienced C or C++ developers because they have a rough idea of the type of code that is tedious to do in C.
当我开始使用 Python 时，我也这么认为，
在 12 年内我已经完成了两次步骤 3（我记得）。称其为设计模式还不够频繁。通常包装现有的 C 库就足够了。通常其他人已经编写了包装器。
I also thought that way when I started using Python
I've done step 3 twice (that I can recall) in 12 years. Not often enough to call it a design pattern. Usually it's enough to wrap an existing C library. Usually someone else has already written the wrapper.
第3步是错误的。在现代世界中，超过一半的时间“慢位”是 I/O 或网络限制，或者受到进程外部的某些其他资源的限制。用任何东西重写它们只会引入错误。
Step 3 is wrong. In the modern world, more than half the time "the slow bits" are I/O or network bound, or limited by some other resource outside the process. Rewriting them in anything is only going to introduce bugs.
Mercurial 就是一个很好的例子：它是用 Python 和 C 编写的，并且与 git 一样快，大部分是用C编写的。
Mercurial is a good example: it's written in Python and C and it's about as fast as git, which is mostly written in C.