
IT 行业发展至今日,编程语言数不胜数,每种编程语言都有自己的用户。为了证明自己使用的语言比其他的语言好,用户们经常在网上争论不休。其中,最常拿来比较的就是编程语言的运行速度,然而通过速度来比较编程语言的好坏,这种做法就正确吗?
事实上,由于测试代码过于简单,很多速度测试都不够客观。在实际应用中,我们常常需要编写大量重复度低的业务逻辑;但在速度测试中,为了保证公平性,测试人员往往会用同一段代码测试每种语言,并且为了减少工作量,他们不会使用复杂代码,而是选择重复度高的代码(比如计算斐波那契数列)。同时,测试者为了让代码运行时间更长、测试结果更明显,还常常在速度测试中使用大数据 —— 可这也会导致数据无法放入 CPU 的 L1 缓存(大部分 CPU 的 L1 缓存仅有几十 KB)。要知道,L1 缓存的运行速度远高于 L2 和 L3 缓存,如此一来,这类测试结果便完全无法反映真实应用场景。
另外,前一段时间 GitHub 上有一个热度很高的编程语言速度排行榜,它使用的测试代码是计算莱文斯坦距离(Levenshtein Distance,一种衡量两个字符串差异的字符串度量标准,指通过插入、删除或替换单个字符,将一个字符串转换成另一个所需的最少操作次数),结果显示第一名 Fortran “吊打” 了第二名 C 语言。尽管这个结果看似很有说服力,但有技术专家发现,该测试中用于 Fortran 的代码被额外添加了优化逻辑,导致测试条件并不公平。
编程语言的速度排行榜,其实就像手机跑分 —— 跑分高低并不能代表它是否适合某个用户。就好比喜欢拍照的人会更关注手机的摄像头配置,经常出门的人会更看重手机的续航能力;对于开发者而言,编程语言的复杂度、语法规则的友好度,往往对选择更具决定性作用。这也是为什么 JavaScript 和 Python 即便运行速度不算快,也常常成为开发首选。
说到底,这个世界上没有哪种编程语言是 “六边形战士”,更不存在绝对 “最好” 的编程语言 —— 选择的核心,永远是 “适配场景”。