python - Windows 上不一致的 Python 性能

Question

我有一些正在处理的 Python 2.7 代码，它在任何 *nix 类型的系统上都运行良好。但是，在 Windows 上，同一段代码的执行时间将大相径庭。请注意下面我的调试输出。 t 是每次通过的总时间，s 是生成数据的时间，u 是通过串行方式将该数据发送到我的设备的时间(均以毫秒为单位)。

t: 9 - s: 3 - u: 6
t: 14 - s: 9 - u: 5
t: 9 - s: 3 - u: 6
t: 9 - s: 3 - u: 6
t: 15 - s: 8 - u: 7
t: 14 - s: 9 - u: 5
t: 11 - s: 5 - u: 6
t: 15 - s: 9 - u: 6
t: 14 - s: 9 - u: 5
t: 13 - s: 8 - u: 5
t: 15 - s: 9 - u: 6
t: 15 - s: 9 - u: 6
t: 14 - s: 8 - u: 6
t: 11 - s: 6 - u: 5
t: 11 - s: 5 - u: 6
t: 15 - s: 8 - u: 7
t: 15 - s: 10 - u: 5
t: 7 - s: 2 - u: 5
t: 15 - s: 9 - u: 6
t: 15 - s: 9 - u: 6
t: 13 - s: 7 - u: 6
t: 12 - s: 7 - u: 5
t: 12 - s: 6 - u: 6
t: 15 - s: 9 - u: 6
t: 8 - s: 2 - u: 6
t: 14 - s: 9 - u: 5
t: 15 - s: 9 - u: 6
t: 14 - s: 9 - u: 5
t: 15 - s: 9 - u: 6
t: 14 - s: 8 - u: 6
t: 14 - s: 9 - u: 5
t: 14 - s: 9 - u: 5
t: 9 - s: 4 - u: 5
t: 11 - s: 5 - u: 6

串行发送时间不是问题，通常非常一致。是“s”步骤，它实际生成有问题的数据，在任何地方都需要 2 到 9 毫秒。相当大的摆动!在 Debian 上(甚至在 raspberry pi 上运行)这部分需要非常一致的 11-12 毫秒。

围绕这个还有很多其他代码，但“s”时间表示的步骤基本上是这样的:

    buf = [wheel_helper(self._vector[y][x], h, s) for y in range(h) for x in range(w)]
    buf = [i for sub in buf for i in sub]
    self._led.setBuffer(buf)

它在矩阵上生成彩虹图案，颜色基于距中心的距离。但这就是它每次 所做的全部。我看不出为什么它会随时间变化如此之大。

有什么想法吗？

更新:您通常可以忽略我为“s”步骤运行的代码。这只是许多中的一个示例，所有这些示例的运行时间都非常可变。有些使用范围，有些则没有。到处都是，但它始终是一个问题。

更新 2:

好吧，我做了一些进一步的测试并制作了一个非常简单且不使用范围的示例!它计算斐波那契数列的前 1000 个元素 1000 次。很简单，对吧？但在 Windows 上，最快运行和最慢运行之间的差异将延长近 375%(下面示例输出中的最大/最小)。所有计时值均为毫秒。

import time
import math
min = 10
max = 0
avg = 0
sum = 0
count = 0
def msec():
    return time.clock() * 1000.0

def doTime(start):
    global min
    global max
    global avg
    global sum
    global count
    diff = msec() - start
    if diff < min: min = diff
    if diff > max: max = diff
    sum += diff
    avg = sum/count
    print "Curr {:.3f} | Min {:.3f} | Max {:.3f} | Max/Min {:.3f} | Avg {:.3f}".format(diff, min, max, max/min, avg)



h = 24
w = 24
while count < 1000:
    start = msec()

    #calculate the first 1000 numbers in the fibonacci sequence
    x = 0
    while x < 1000:
        a = int(((((1 + math.sqrt(5)) / 2) ** x) - (((1 - math.sqrt(5)) / 2) ** (x))) / math.sqrt(5))
        x+=1

    count+=1
    doTime(start)

事实证明，Mac 也不能幸免，但在最慢的运行时，Mac 的运行时间只延长了 75%。我尝试在 Linux 上运行，但它似乎无法实现微秒级的时间分辨率，因此数字四舍五入到最接近的毫秒。

Windows: Curr 2.658 | Min 2.535 | Max 9.524 | Max/Min 3.757 | Avg 3.156

Mac: Curr 1.590 | Min 1.470 | Max 2.577 | Max/Min 1.753 | Avg 1.554

Answer 1

我相信这是由于范围。为此，旧版本的 python (2.X) 同时具有 range 和 xrange。但是 xrange 比 range 更高效，因为 xrange 仅在需要时生成列表(即返回生成器)，而 range 生成整个列表(因此效率低下，假设您有一个从 1 到 100000 的列表)

因此，如果您的列表规模在增加，range 的使用可能是您的流程变慢的原因。