Tengo un código Python 2.7 en el que estoy trabajando y funciona muy bien en cualquier sistema de tipo * nix. Sin embargo, en Windows, la misma sección de código tendrá tiempos de ejecución muy diferentes. Tenga en cuenta mi salida de depuración a continuación. t es el tiempo total para cada pase, s es el tiempo para generar los datos y u es el tiempo para enviar esos datos en serie a mi dispositivo (todo en milisegundos).

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

El tiempo de envío en serie no es un problema y generalmente es muy consistente. Es el paso "s", donde en realidad genera los datos que son problemáticos, llevándose a cualquier lugar durante 2 a 9 milisegundos. ¡Qué gran swing! En Debian (incluso en una frambuesa pi), esta porción tarda entre 11 y 12 ms.

Hay muchos otros códigos en torno a esto, pero el paso indicado por el tiempo "s" es básicamente el siguiente:

    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)

Genera un patrón de arcoíris en una matriz donde el color se basa en su distancia desde el centro. Pero eso estodas que lo hacecada hora. No veo ninguna razón por la que deba variar en el tiempo tan salvajemente.

¿Alguna idea?

Actualizar: Generalmente puede ignorar el código que estoy ejecutando para el paso "s". Este es solo un ejemplo demuchos, todo lo cual se ejecuta en una cantidad de tiempo muy variable. Algunos usan el rango, otros no. Está por todas partes, pero siempre es un problema.

Actualización 2:

Ok, hice algunas pruebas adicionales e hice un ejemplo que es muy simple yno lo hace usar rango! Calcula los primeros 1000 elementos de la secuencia de Fibonacci 1000 veces. Bastante simple, ¿verdad? Pero en Windows, la diferencia entre la ejecución más rápida y la más lenta sería casi un 375% más larga (Max / Min en la salida de ejemplo a continuación). Todos los valores de tiempo son milisegundos.

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)

Resulta que Mac no es inmune, pero es mejor con solo un 75% más de tiempo para la carrera más lenta. Intenté ejecutar en Linux, pero no tendrá una resolución de sincronización de microsegundos, por lo que parece que los números se redondearon mal al ms más cercano.

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