这一篇文┞仿琅绫擎，我一向在谈论最重要的是开辟时光。所以问题依然存在：当就开辟时光而言，Python 要比其他说话更快吗?按惯例惯例来看，我、google 还有其他几小我可以告诉你 Python 是多么的高效。它为你抽象出很多器械，赞助你存眷那些你真正应当编写代码的处所，而不会被困在琐碎工作的杂草里，比如你是否应当应用一个向量或者一个数组。但你可能不爱好只是听别人说的┞封些话，所以让我们来看一些更多的经验数据。
在大年夜多半情况下，关于 python 是否是更高效说话的┞幅论可以归结为脚本说话(或动态说话)与静态类型说话两者的┞幅论。我认为人们广泛接收的是静态类型说话的临盆力较低，然则，这有一篇优良的论文说清楚明了为什么不是如许。就 Python 而言，这里有一项研究，它查询拜访了不合说话编写字符串处理的代码所须要花费的时光，供参考。
在上述研究中，Python 的效力比 Java 赶过 2 倍。有一些其他研究也显示类似的器械。 Rosetta Code 对编程说话的差别进行了深刻的研究。在论文中，他们把 python 与其他脚本说话/解释性说话比拟较，得出结论：
- Python 更简洁，即使与函数式说话比拟较(平均要短 1.2 到 1.6 倍)
广泛的趋势似乎是 Python 中的代码行老是更少。代码行听起来可能像一个恐怖的指标，然则包含膳绫擎已经提到的两项研究在内的多项研究注解，每种说话中每行代码所须要花费的时光大年夜约是一样的。是以，限制代码行数就可以进步临盆效力。甚至 codinghorror(一名 C# 法度榜样员)本人写了一篇关于 Python 是若何更有效力的文┞仿。
我认为说 Python 比其他的很多说话加倍的有效力是公平的。这主如果因为 Python 有大年夜量的自带以及第三方库。如不雅你不知道为何 Python 是如斯的小巧和高效，我邀请你借此机会进修一点 python，本身多实践。这儿是你的第一个法度榜样：
- import __hello__
然则如不雅速度真的重要呢?
上述论点的语气可能会让人认为优化与速度一点也不重要。但事实是，很多时刻运行时机能真的很重要。一个例子是，你有一个 web 应用法度榜样，个中有一个特定的端点须要用很长的时光来响应。你知道这个法度榜样须要多快，并且知道法度榜样须要改进若干。
在高吞吐量的情况中应用解释性说话似乎是抵触的，然则我们已经发明 CPU 时光几乎不是限制身分;说话的表达性是指，大年夜多半法度榜样是源法度榜样，同时它们的大年夜多半时光花费在 I/O 读写和本机的运行时代码上。并且，解释性说话无论是在说话层面的轻松实验照样在许可我们在很多机械膳绫渠索分布计算的办法都是很有赞助的，
你可能会说，“前面说的情况真是太好了，然则我们确切有过一些问题，这些问题中 CPU 成为了我们的瓶颈，并造成了我们的 web 应用的速度十分迟缓”，或者“在办事器上 X 说话比 Y 说话须要更少的硬件资本来运行。”这些都可能是对的。关于 web 办事器有如许的好梦的工作：你可以几乎无穷地负载均衡它们。换句话说，可以在 web 办事器上投入更多的硬件。当然，Python 可能会比其他说话请求更好的硬件资本，比如 c 说话。只是把硬件投入在 CPU 问题上。比拟于你的时光，硬件就显得异常的便宜了。如不雅你在一年内节俭了两周的临盆力时光，那将远远多于所增长的硬件开销的回报。
在我们的例子中，产生了两件事：
- 我们留意到有一个端点履行迟缓。
- 我们承认它是迟缓，因为我们有一个可以衡量是否足够快的标准，而它没达到那个标准。
我们不必在应用法度榜样中微调优化所有内容，只须要让个中每一个都“足够快”。如不雅一个端点花费了几秒钟来响应，你的用户可能会留意到，然则，他们并不会留意到你将响应时光由 35 毫秒降低到 25 毫秒。“足够好”就是你须要做到的所有工作。免责声明: 我应当说有一些应用法度榜样，如及时投标法度榜样，确切须要细微优化，每一毫秒都相当重要。但那只是例外，而不是规矩。
为了明白若何对端点进行优化，你的第一步将是设备代码，尝尝试找出瓶颈在哪。毕竟：
- 任何除了瓶颈之外的改进都是错觉。Any improvements made anywhere besides the bottleneck are an illusion. -- Gene Kim
如不雅你的优化没有触及到瓶颈，你只是浪费你的时光，并没有解决实际问题。在你优化瓶颈之前，你不会获得任何重要的改进。如不雅你在不知道瓶颈是什么前就测验测验优化，那么你最终只会在朝分代码中玩耍。在测量和肯定瓶颈之前优化代码被称为“过早优化”。人们常说起 Donald Knuth 说的话，但他声称这句话实际上是他大年夜别人那边听来的：
- 过早优化是万恶之源Premature optimization is the root of all evil。
在谈到保护代码库时，来自 Donald Knuth 的更完全的引文是：
- 在 97% 的时光里，我们应当忘记眇乎小哉的效力：过早的优化是万恶之源。然而在关 键的 3%，我们不该该错过优化的机会。 —— Donald Knuth
换句话说，他所说的是，在大年夜多半时光你应当忘记对你的代码进行优化。它几乎老是足够好。在不是足够好的情况下，我们平日只须要触及 3% 的代码路径。比如因为你应用了 if 语句而不是函数，你的端点快了几纳秒，但这并不会使你博得任何奖项。
过早的优化包含调用某些更快的函数，或者甚至应用特定的数据构造，因为它平日更快。计算机科学认为，如不雅一个办法或者算法与另一个具有雷同的渐近增长(或称为 Big-O)，那么它们是等价的，即使在实践中要慢两倍。计算机是如斯之快，算法跟着数据/应用增长而造成的计算增长远远跨越实际速度本身。换句话说，如不雅你有两个 O(log n) 的函数，然则一个要慢两倍，这实际上并不重要。跟着数据范围的增大年夜，它们都以同样的速度“慢下来”。这就是过早优化是万恶之源的原因;它浪费了我们的时光，几乎大年夜来没有真正有助于我们的机能改进。
推荐阅读
传统的交换机操作体系(简称NOS)对大年夜众是一个相对封闭的范畴。跟着白牌交换机的高速增长，NOS纷纷开源，NOS的开辟者也大年夜只有设备商工程师，扩大年夜到互联网，运营商以及云计算的大>>>详细阅读
地址：http://www.17bianji.com/lsqh/34995.html
1/2 1
网友点评
精彩导读
科技快报
品牌展示