2016-06-05 5 views
1

Ich habe meinen Code getestet, um den Leistungsunterschied zwischen einer For - und einer Foreach - Schleife zu sehen (wollte sehen, wie er mein Programm aus Neugier beeinflusste) und beim Messen der Ticks bemerkte ich, dass es einen sporadischen Sprung geben würde Zeit, die dauerte, als die Liste in einer For-Schleife leer war.For Schleife nimmt zufällig mehr Ticks?

beispielsweise ein Teil der Ausgabe in dem Konsolenfenster liest [...], 2, 4, 4, 2, 5, 4, 2, 26 , 3, 1, 27 , 2, 2, 1, 3, 2, 2, [...].

Während ich merke, dass diese Ticks für solch eine kleine Zeitintervallmessung nachlässig auf die endgültige Leistung meiner Anwendung sind, bin ich neugierig, warum es so einen Sprung gibt. Wiederum wurden diese Zahlen genommen, während ich wusste, dass die Liste leer war, also gab es nichts, worüber ich wirklich referieren konnte.

Die Objekte in der Schleife sind Wörterbücher; Insbesondere haben sie Ints für Schlüssel und benutzerdefinierte Klassen für ihre Werte.

Stoppuhr.Frequenz gibt mir 2533211 (Ich musste mein System nicht neu starten, da ich die vorherigen Messungen nahm).

-Code -

public void Update(int gameTime) 
    { 
     watch.Restart(); 
     for (int i = 0; i < _movementComponents.Count; ++i) 
     { 
      _positionComponents[i].Position += _movementComponents[i].Velocity * gameTime; 
      _movementComponents[i].Velocity = Vector2.Zero; 
     } 
     watch.Stop(); 
     Console.WriteLine("Loop took " + watch.ElapsedTicks + " ticks"); 
    } 
+1

Garbage Collection vielleicht? – user1666620

+0

Welche Objekte bearbeiten und erstellen Sie in der Schleife? Meine erste Schätzung wäre der GC. Vor allem, wenn Sie dort keine Werttypen verwenden. – Joey

+2

Die Häufigkeit für Ticks ist ziemlich relevant. Ist diese Nanosekunden-Ebene? Mikrosekunden? Könnte Cache-Misses, Kontextwechsel usw. sein. – Zong

Antwort

1

Ich habe ein solches Experiment mit einer leeren Schleife. Die gleichen zufälligen Verzögerungen sind auch dort zu finden. Hier sind ein paar Gründe dafür, dass ich mir vorstellen kann:

  • Interrupts (Netzwerk, Maus, Timer tickt, IO Vervollständigungen durch andere Prozesse verursacht, Musik-Player, USB-Gerät isochronen Transfers, ...)
  • Threads mit hoher Priorität arbeiten nur sehr wenig, bevor sie schlafen gehen. Ich kann mir keinen konkreten solchen Thread vorstellen, aber ich weiß, dass das ein Grund ist. Wenn Sie Ihren eigenen Thread und Prozess in Echtzeit setzen, wird das Latenzprofil erheblich komprimiert.
  • Vielleicht berühren Sie Speicherseiten, die sich auf der Standby-Liste befinden. Dies bedeutet, dass beim Zugriff ein weicher Seitenfehler auftritt.
  • Der Garbage Collector kann möglicherweise etwas anderes als diese Schleife ausgelöst werden.
+0

Sie konnten immer überprüfen, ob ein GC aufgerufen wurde, indem Sie die GC-Anzahl von Gen 0 überprüfen. – Enigmativity