Windows 上的 Python 性能不一致 [英] Inconsistent Python Performance on Windows
问题描述
我有一些正在处理的 Python 2.7 代码，它适用于任何 *nix 类型系统.但是，在 Windows 上，同一部分代码的执行时间会有很大不同.请注意下面我的调试输出.t 是每次传递的总时间，s 是生成数据的时间，u 是通过串行方式将数据发送到我的设备的时间(均以毫秒为单位).
I have some Python 2.7 code I'm working on and it works great on any *nix type system. However, on windows the same section of code will have wildly different execution times. Note my debug output below. t is the total time for each pass, s is the time to generate the data and u is the time to send that data over serial to my device (all in milliseconds).
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 毫秒.
The serial send time is not a problem and generally very consistent. Is the "s" step, where it actually generates the data that is problematic, taking anywhere for 2 to 9 milliseconds. Quite a huge swing! On Debian (running on a raspberry pi even) this portion takes a very consistent 11-12 ms.
围绕此还有很多其他代码，但s"时间表示的步骤基本上是这样的:
There's a lot of other code around this but the step denoted by the "s" time is basically this:
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)
它在矩阵上生成彩虹图案，其中颜色基于其与中心的距离.但这就是所有每次.我看不出它为什么会随时间变化如此剧烈.
It generates a rainbow pattern on a matrix where the color is based on its distance from the center. But that is all that it does every time. I see no reason why it should vary in time so wildly.
有什么想法吗?
更新:您通常可以忽略我为s"步骤运行的代码.这只是许多的一个例子，所有这些都在非常可变的时间内运行.有些正在使用范围，有些则没有.到处都是，但总是有问题.
Update: You can generally ignore the code that I'm running for the "s" step. This is just one example of many, all of which run in a very variable amount of time. Some are using range, some aren't. It's all over the board, but it's always a problem.
更新 2:
好的，我做了一些进一步的测试并制作了一个非常简单且不使用范围的示例！它计算斐波那契数列的前 1000 个元素 1000 次.很简单，对吧?但在 Windows 上，最快运行和最慢运行之间的差异将增加近 375%(以下示例输出中的最大/最小值).所有计时值均为毫秒.
Ok, I did some further testing and made an example that's very simple and doesn't use range! It calculates the first 1000 elements of the fibonacci sequence 1000 times. Pretty simple, right? But on Windows the difference between quickest run and slowest would be nearly 375% longer (Max/Min in example output below). All timing values are milliseconds.
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 并不能幸免，但在最慢的运行中仅延长 75% 的时间就更好了.我尝试在 Linux 上运行，但它不会进行微秒计时分辨率，因此数字四舍五入到最接近的毫秒.
Turns out that Mac isn't immune, but better at only 75% longer for the slowest run. I tried to run on Linux but it won't do microsecond timing resolution it would seem so the numbers were rounded badly to the nearest ms.
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
推荐答案
我没有看到任何问题.您有执行串行 IO 的代码，这将阻止您的进程并可能调用调度程序.如果发生这种情况，它会首先将控制权交给另一个流程，只有当该流程产出或超过其时间片时，它才会重新安排您的流程.
I don't see anything problematic. You have code that performs serial IO, which will block your process and possibly invoke the scheduler. If that happens, it will first give control to a different process and only when that one yield or exceeds its timeslice it will re-schedule your process.
您的问题是:您正在运行的系统的调度程序时间片的大小是多少?我相信这会让您深入了解正在发生的事情.
The question for you is: What is the size of the scheduler timeslice of the systems you are running? I believe that this will give you an insight into what is happening.
这篇关于Windows 上的 Python 性能不一致的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
