У меня есть код 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 не защищен, но лучше всего на 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