关于python语言优化的一些思考

myjy1818 · · 1158 次点击 · 开始浏览    置顶
这是一个创建于 的主题,其中的信息可能已经有所发展或是发生改变。

【79196062】最近一直在做python工程化相关的工作,颇有心得,遂总结一下。 一是为了整理思绪,二是为了解放自己健忘的大脑。 python是一个C的语法糖盒子 原生的python通常都是由cpython实现,而cpython的运行效率,确实让人不敢恭维,比较好的解决方案有cython、numba、pypy等等 cython 是目前我认为发展最好,最靠谱的一项Python加速解决方案。 cython 使用cython编译过后的代码,通常会对原python代码有2倍以上的速度提升。cython的编译也很简单,只需要构建一个setup.py,然后执行: python setup.py build_ext numba numba numba也是我比较看好的,它的亮点在于使用装饰器的方式应用jit技术,例如下面的代码: @jit def run_xxx(): ... 可直接将run_xxx方法进行高效的c编译。 但在大多数应用场景下(尤其是采取了服务拆分或微服务的架构策略),这种功能反而让人有种鸡肋的感觉 只能说numba更适用于模型开发的场景,在模型应用和部署的环节,numba的作用很尴尬 pypy pypy pypy相对比较小众,这是由于它本身的限制条件较多,尤其是对python第三方包的支持上面更是非常局限。由于我在做python开发的过程中,经常需要限制版本,以及引入较多的第三方包,所以pypy就不在考虑的范围内了 不要轻易相信声称自己很快的模块和方法 曾经在网上看到有人发文,声称numpy是目前python下非常高效的一个模块,而numpy的“娘亲们”,甚至把自己夸上了天,说自己如何如何高效。而国内的一些伪专家们,也是盲目的“助纣为虐”,说什么如果你不太懂,请不要轻易去优化numpy云云,难道你自认为优化的算法能胜过numpy里内置的久经考验的算法? 真的是误人子弟!很多人在这里就被唬住了,代码分析到numpy的环节,就不敢往下走了。 我想说的是,对一切永远保持怀疑的精神才是真正的科学素养,是不是真的高性能,一切要用数据说话。 刚开始,我也被短暂的唬住了,毕竟numpy的底层也没接触过,但profiler分析的结果告诉我,问题就出在numpy里,结果发现在我的项目场景里,使用dict能完全替代numpy的所有操作,性能一下提高了很多,而numpy的高效在于ndarray ndarray 所以,采取什么数据结构要看应用场景,没有万能的高效数据结构 不要以为排除法是万能的 优化代码的过程中,因为我的以往成功“经验”,也导致走了不少弯路,最主要的,就是盲目使用排除法。使用排除法只能使用二分查找或快排的策略去组织代码,如果目标代码比较少还可以,事实上,在真实场景中往往有成百上千行目标代码。人工执行和实现O(logN)量级的操作,似乎是一种蛮干。 这里有几个度量工具顺便记录下: py_spy https://github.com/benfred/py-spy 方便的生成CPU执行方法的火焰图 line_profiler https://github.com/rkern/line_profiler 逐行代码分析,不要小看它的能力,它还可以指定要分析的方法和模块 量变真的会引起质变 在很多人的习惯性逻辑思维里,一个程序的性能,随着代码的优化,会是一条平滑的增长曲线。但实践表明,这个逻辑确实有问题。 通过不断对代码的优化,我发现,程序的性能到达一定阶段会发生“突变”,或者“阶跃”。上一次优化的执行时间几百毫秒,下一次优化后的执行时间竟然只有几十毫秒,说发生了“阶跃”一点都不夸张。 为什么会这样? 至少在我的朋友圈里,还没有人能给我令人信服的答案,我自认为比较可靠的理解是,现代操作系统在cpu指令的处理上,对cpu的任务分配还不是那么“流畅”。 哪位朋友有好的见解,欢迎批评指正!

有疑问加站长微信联系(非本文作者)

入群交流(和以上内容无关):加入Go大咖交流群,或添加微信:liuxiaoyan-s 备注:入群;或加QQ群:692541889

1158 次点击  
加入收藏 微博
暂无回复
添加一条新回复 (您需要 登录 后才能回复 没有账号 ?)
  • 请尽量让自己的回复能够对别人有帮助
  • 支持 Markdown 格式, **粗体**、~~删除线~~、`单行代码`
  • 支持 @ 本站用户;支持表情(输入 : 提示),见 Emoji cheat sheet
  • 图片支持拖拽、截图粘贴等方式上传