python与bc在计算6^6^6中的比较

Question

我将分别使用6^6^6和python来评估表达式bc。

python文件的内容是print 6**6**6。当我执行time python test.py时，我得到的输出如下

real        0m0.067s
user        0m0.050s
sys         0m0.011s

然后，我运行命令time echo 6^6^6 | bc，它为我提供了以下输出

real        0m0.205s
user        0m0.197s
sys         0m0.005s

结果表明，python和bc的sys时间分别为11 5ms和5 5ms。在sys时间级别，bc命令的性能优于python，但对于用户和实时，python的速度几乎是bc的4倍。可能去过的地方。我还没有对这些过程给予任何优先级。我正在努力理解这种情况。

Answer 1

Python在启动时导入大量文件：

% python -c 'import sys; print len(sys.modules)'
39

每一种方法都需要更多的尝试来打开Python文件，因为有许多方法可以定义模块：

% python -vv -c 'pass'
# installing zipimport hook
import zipimport # builtin
# installed zipimport hook
# trying site.so
# trying sitemodule.so
# trying site.py
# trying site.pyc
# trying /System/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site.so
# trying /System/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/sitemodule.so
# trying /System/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site.py
# /System/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site.pyc matches /System/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site.py
import site # precompiled from /System/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site.pyc
# trying os.so
# trying osmodule.so
# trying os.py
# trying os.pyc
# trying /System/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/os.so
# trying /System/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/osmodule.so
# trying /System/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/os.py
# /System/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/os.pyc matches /System/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/os.py
import os # precompiled from /System/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/os.pyc
    ...

每个“尝试”，除了那些内置的，都需要一个os级/系统调用，而每个“导入”似乎会触发大约8条“尝试”消息。(使用zipimport可以减少这种情况，您的PYTHONPATH中的每个路径都可能需要另一个调用。)

这意味着在Python在我的机器上启动之前，有将近200个stat系统调用，而"time“将其分配给"sys”而不是" user "，因为用户程序正在等待系统进行操作。

相比之下，就像terdon所说的，"bc“没有那么高的启动成本。查看d桁架输出(我有一个Mac；基于Linux操作系统的"strace“)，我发现bc本身不会进行任何打开()或stat()系统调用，除了加载一些共享库之外，这当然也是Python的开始。此外，Python在准备处理任何东西之前，还有更多的文件要读取。

等待磁盘的速度很慢。

您可以通过以下操作了解Python的启动成本：

time python -c pass

在我的机器上是0.032s，而'print 6*6**6‘是0.072 s，因此启动成本是总时间的1/2，计算+转换为小数的另一半。同时：

time echo 1 | bc

需要0.005s，而"6^6^6“需要0.184 s，所以bc的指数比Python慢4倍以上，尽管它的开始速度要快7倍。

Answer 2

我会从另一个角度来解释。

公平地说，bc具有优势，因为它不需要从磁盘读取任何东西，只需要它的blob/二进制文件，而python必须导入一系列模块+读取文件。因此，您的测试可能倾向于bc。要真正测试它，您应该使用bc -q file，其中file包含：

6^6^6
quit

仅更改该更改更改了使用echo的时间：

bc  0.33s user 0.00s system 80% cpu 0.414 total

若要使用该文件：

bc -q some  0.33s user 0.00s system 86% cpu 0.385 total

(你将不得不使用terdon的方法来发现更大的差异，但至少我们知道它们是不同的)

现在，从python的角度来看，python需要从磁盘读取、编译和执行每次文件，加上加载模块作为安德鲁，这使得执行时间更慢。如果编译python脚本的字节代码，您将注意到执行代码所需的总时间减少了50%：

python some.py > /dev/null  0.25s user 0.01s system 63% cpu 0.413 total

汇编：

./some.pyc  0.22s user 0.00s system 77% cpu 0.282 total

如您所见，有几个因素可以影响不同工具之间的时间执行。