如何自动优化Python应用程序？
我有一个复杂的 Python 服务器应用程序，它是基于批处理的。我希望这个应用程序能够尽可能快地运行。在此应用程序中，可能有大约 100 个整数常量会以某种方式影响应用程序的性能。这些可能类似于字典的初始大小< /a>，设置外部程序的内存限制。
我想做的是让优化程序能够修改这 100 个整数值，并在夜间运行数千次测试，并找出哪些参数集可以让 Python 程序在最短的时间内完成。
这样的事存在吗？我想我可以使用 EXEC 语句和替换函数来以某种方式构建它来修改整数。
I have a complex Python server application, which is batch based. I want this application to work as fast a possible. In this application there are probably something like 100 integer constants that somehow affect the performance of the application. These could be something like the initial size of a dictionary, setting memory constraints of external programs.
What I would like to do is to enable an optimizer program to modify these 100 integer values and run thousands of tests over night and figure out what set of parameters would have the Python program finish in the shortest time.
Does such a thing exist? I imagine that I could build this somehow using the EXEC statement and the replace function to modify the integers.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
如果每个变量的影响独立于其他变量，那么您可以使用脚本依次优化每个变量来实现这一点...如果每个变量可以假设 k 个值并且有 n 个变量，则这是 O(nk)。如果变量可能以完全任意的方式影响彼此对性能的影响，则必须枚举并测试所有 O(k^n) 分配。如果您处于两者之间，那么描述算法就会变得有点困难。
关于机制，一旦您弄清楚什么配置是有意义的（如上所述），使用例如 exec 或 time 的简单脚本/程序就应该可以工作。即使确实存在工具，您仍然需要上述问题的答案，以避免暴力 O(k^n) 解决方案……或者认识到这是您能做的最好的事情。
If the effect of each variable is independent of the other variables, you can feasibly do this using a script to optimize each variable in turn... if each variable can assume k values and there are n variables, this is O(nk). If the variables may affect each other's effect on performance is completely arbitrary ways, you would have to enumerate and test all O(k^n) assignments. If you're somewhere in between, it makes describing an algorithm a little harder.
Regarding the mechanics, as soon as you figure out what configurations are meaningful (as in above), a simple script/program using e.g. exec or time should work. Even if a tool did exist, you'd still need an answer to the above to avoid the brute-force O(k^n) solution... or recognize that this is the best you can do.