Ich habe Python 2.7-Code, an dem ich arbeite, und er funktioniert auf allen * nix-Systemen hervorragend. Unter Windows hat derselbe Codeabschnitt jedoch sehr unterschiedliche Ausführungszeiten. Beachten Sie meine Debug-Ausgabe unten. t ist die Gesamtzeit für jeden Durchgang, s ist die Zeit zum Generieren der Daten und u ist die Zeit, um diese Daten seriell an mein Gerät zu senden (alle in Millisekunden).

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

Die serielle Sendezeit ist kein Problem und im Allgemeinen sehr konsistent. Ist der "s" -Schritt, bei dem die problematischen Daten tatsächlich generiert werden, und der 2 bis 9 Millisekunden dauert. Ein ziemlicher Riesenschwung! Unter Debian (läuft sogar auf einem Himbeer-Pi) dauert dieser Teil 11-12 ms.

Es gibt noch viel anderen Code, aber der durch die "s" -Zeit angegebene Schritt lautet im Grunde:

    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)

Es erzeugt ein Regenbogenmuster auf einer Matrix, bei der die Farbe auf dem Abstand vom Mittelpunkt basiert. Das ist aberalle das tut esjeder Zeit. Ich sehe keinen Grund, warum es in der Zeit so wild variieren sollte.

Irgendwelche Gedanken?

Aktualisieren: Sie können den Code, den ich für den "s" -Schritt ausführe, im Allgemeinen ignorieren. Dies ist nur ein Beispiel fürviele, die alle in einer sehr variablen Zeitspanne ablaufen. Einige nutzen die Reichweite, andere nicht. Es ist alles auf der ganzen Linie, aber es ist immer ein Problem.

Update 2:

Ok, ich habe einige weitere Tests durchgeführt und ein Beispiel gemacht, das sehr einfach ist undnicht Reichweite nutzen! Die ersten 1000 Elemente der Fibonacci-Sequenz werden 1000-mal berechnet. Ziemlich einfach, oder? Unter Windows wäre der Unterschied zwischen schnellstem und langsamstem Lauf jedoch fast 375% länger (Max / Min in der folgenden Beispielausgabe). Alle Zeitwerte sind Millisekunden.

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)

Es stellt sich heraus, dass der Mac nicht immun ist, aber für den langsamsten Lauf um nur 75% länger ist. Ich habe versucht, unter Linux zu laufen, aber es wird keine Zeitauflösung im Mikrosekundenbereich erreichen. Es scheint also, dass die Zahlen schlecht auf die nächste Millisekunde gerundet wurden.

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