面试题:为什么python性能差

Python013

面试题:为什么python性能差,第1张

当我们提到一门编程语言的效率时:通常有两层意思,第一是开发效率,这是对程序员而言,完成编码所需要的时间;另一个是运行效率,这是对计算机而言,完成计算任务所需要的时间。编码效率和运行效率往往是鱼与熊掌的关系,是很难同时兼顾的。不同的语言会有不同的侧重,python语言毫无疑问更在乎编码效率,life is short,we use python。

虽然使用python的编程人员都应该接受其运行效率低的事实,但python在越多越来的领域都有广泛应用,比如科学计算 、web服务器等。程序员当然也希望python能够运算得更快,希望python可以更强大。

首先,python相比其他语言具体有多慢,这个不同场景和测试用例,结果肯定是不一样的。这个网址给出了不同语言在各种case下的性能对比,这一页是python3和C++的对比,下面是两个case:

python运算效率低,具体是什么原因呢,下列罗列一些

第一:python是动态语言

一个变量所指向对象的类型在运行时才确定,编译器做不了任何预测,也就无从优化。举一个简单的例子: r = a + b。 a和b相加,但a和b的类型在运行时才知道,对于加法操作,不同的类型有不同的处理,所以每次运行的时候都会去判断a和b的类型,然后执行对应的操作。而在静态语言如C++中,编译的时候就确定了运行时的代码。

另外一个例子是属性查找,关于具体的查找顺序在《python属性查找》中有详细介绍。简而言之,访问对象的某个属性是一个非常复杂的过程,而且通过同一个变量访问到的python对象还都可能不一样(参见Lazy property的例子)。而在C语言中,访问属性用对象的地址加上属性的偏移就可以了。

第二:python是解释执行,但是不支持JIT(just in time compiler)。虽然大名鼎鼎的google曾经尝试Unladen Swallow 这个项目,但最终也折了。

第三:python中一切都是对象,每个对象都需要维护引用计数,增加了额外的工作。

第四:python GIL

GIL是Python最为诟病的一点,因为GIL,python中的多线程并不能真正的并发。如果是在IO bound的业务场景,这个问题并不大,但是在CPU BOUND的场景,这就很致命了。所以笔者在工作中使用python多线程的情况并不多,一般都是使用多进程(pre fork),或者在加上协程。即使在单线程,GIL也会带来很大的性能影响,因为python每执行100个opcode(默认,可以通过sys.setcheckinterval()设置)就会尝试线程的切换,具体的源代码在ceval.c::PyEval_EvalFrameEx。

第五:垃圾回收,这个可能是所有具有垃圾回收的编程语言的通病。python采用标记和分代的垃圾回收策略,每次垃圾回收的时候都会中断正在执行的程序,造成所谓的顿卡。infoq上有一篇文章,提到禁用Python的GC机制后,Instagram性能提升了10%。感兴趣的读者可以去细读。

python的整个系统,我其实有非常多的不满。但是用任何一门语言都是取舍问题,如果有一门语言,库够多,已读,易用,性能高,我毫不犹豫立刻转过去。python的强处在于庞大的库,还有非常好的易读和易用性。但是相比来说,性能一直是个问题。python的实现性能大约和C相差五倍上下。如果是大规模计算问题,大约能差10倍以上。当然,我们可以写C扩展,但是这就不是使用python了。我们也可以说,很多时候我们不需要这么快的速度。这是个事实,但是不改变python性能差的事实。 python不但性能差,还有GIL这个玩意。以至于我现在对高并发计算都采取多进程的模式。多进程模式的通讯效率肯定比多线程低,而且麻烦。

另外,python在底层设计上,也表现出很强的实用主义倾向。这是比较外交术语的词汇,更加直白的说法应当是,混乱,不知所谓。在闭包设计上采用free variable设计,而不是lisp中的environs设计。区别?你试试看在外层闭包中from lib import *。由于引入不定个数名称,free variable无法处理。类似的问题还有LEGB规则,新手往往要花很长时间研究这个例子究竟是怎么错的: a = 1 def f(): print a a = 2 我勒个去,这种反直观反人类的事情都有,还敢说自己易读。

还有坑爹的元编程,这东西根本是坑爹中的坑爹货。如果你用过多重继承,大概就知道python的整个OO系统看起来根本是大型的仿真,到处都是乱糟糟的。C++怎么解决多重继承的?你最好别用(真心说,这可比python更加坑爹)。java怎么解决多重继承的,只能继承Interface。其实这是变相的变成了Interface-Implement模式。python怎么解决的?MRO!为什麽一个类加个__metaclass__就会改变性质啊,为什麽一个类去生成另一个类的写法是——我基本不记得了,反正web.py里面有用到,需要的话去炒栗子吧。为什麽方法要隐藏居然要改名字加__啊。你到底是在做OO还是在看起来像OO的东西上狂打补丁啊魂淡。

lambda表达式弱智。我和人讨论过,lambda是否是图灵完备的。结论还是完备的,不过需要借助Y combinator。何必呢?由于强调lambda的快速特性,因此将lambda强制在一行以内(没有结束标记),导致python其实是没有匿名函数的。一个callback数组写的难过死。

语法糖太多了点,当然,这是纯粹的个人感觉。语法糖是把双刃剑,用的好,可以简化编写和阅读,但是太多,往往容易引入语法混乱和额外的约束。

另外,语言的自构建特性混乱。虽说不是每门语言都强调自构建特性,但是通常而言,都是使用C实现一个内核,由内核实现一些基础操作。再由基础操作实现更复杂的操作。每层的边界都是比较清晰的。谁来告诉我,python中有多少库在移植时是由纯python实现的?库的相互依赖层级是?

python的沙盒化也是个问题,如果沙盒做的够好,我完全可以把python作为一个客户级别的平台。用C写一个很简单的类似浏览器的东西,下载一个URL的python包回去运行(或者仅仅检查更新)。从而保证本地效果/跨平台/安全性。现在?一个都保证不了。我连把一个python包转移到另一台同构设备上都很麻烦(如果两者不是严格匹配,例如系统差异,系统版本差异)无论是web开发还是移动终端开发都必须走传统模式。