针对系统资源较低的嵌入式系统优化 Python 运行时的指南
我的团队正在将 Python 2.4.4 运行时合并到我们的项目中，以便利用一些外部开发的功能。
我们的平台具有 450Mhz SH4 应用程序核心和供 Python 运行时和应用程序使用的有限内存。
我们已经移植了 Python，但初始测试强调了以下障碍：
a) Python 运行时的启动时间可能长达 25 秒（当导入相关库及其依赖项时）
b) Python 似乎从来没有在垃圾收集期间向操作系统释放内存 - 唯一的办法是关闭运行时并重新启动（导致上面提到的启动延迟，这通常是不切实际的）
如果我们能够缓解这些问题，我们对 Python 的使用将得到显着改善。 SO 社区的任何指导都非常有价值。尤其是那些了解 Python 执行引擎如何运行的内在知识的人。
My team is incorporating the Python 2.4.4 runtime into our project in order to leverage some externally developed functionality.
Our platform has a 450Mhz SH4 application core and limited memory for use by the Python runtime and application.
We have ported Python, but initial testing has highlighted the following hurdles:
a) start-up times for the Python runtime can be as bad as 25 seconds (when importing the libraries concerned, and in turn their dependencies)
b) Python never seems to release memory to the OS during garbage collection - the only recourse is to close the runtime and restart (incurring start-up delays noted above, which often times is impractical)
If we can mitigate these issues our use of Python would be substantially improved. Any guidance from the SO community would be very valuable. Especially from anyone who has knowledge of the intrinsics of how the Python execution engine operates.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
也许很难相信，CPython 2.4 版本永远不会向操作系统释放内存。据称，这个问题已在 Python 2.5 版本中修复。
此外，Python 2.5 和 Python 2.6 的性能（处理器方面）也得到了改进。
请参阅 Python 2.5 新增功能中的 C API 部分< /a>，查找名为 Evan Jones's patch to obmalloc
Alex Martelli 的项目（至少应始终考虑其建议），说多进程是释放内存的唯一方法。如果你不能使用
多处理（Python 2.6 中的模块），os.fork至少可用。以最原始的方式使用 os.fork（在开始时分叉一个工作进程，等待它完成，分叉一个新的..）仍然比花费 25 秒重新启动解释器要好。Perhaps it is hard to believe, but CPython version 2.4 never releases memory to the OS. This is allegedly fixed in verion Python 2.5.
In addition, performance (processor-wise) was improved in Python 2.5 and Python 2.6 on top of that.
See the C API section in What's new in Python 2.5, look for the item called Evan Jones’s patch to obmalloc
Alex Martelli (whose advice should always be at least considered), says multiprocess is the only way to go to free memory. If you cannot use
multiprocessing(module in Python 2.6),os.forkis at least available. Using os.fork in the most primitive manner (fork one work process at the beginning, wait for it to finish, fork a new..) is still better than relauching the interpreter paying 25 seconds for that.