Programm wird langsamer

Nukularfüsiker

Zaus schrieb:

- Der Vorschlag ist nicht umsetzbar weil mit dem Programm Musik erzeugt wird und es nicht aktzeptabel ist wenn 2 Noten auf einmal 50-100ms näher aufeinander folgen als sie sollen nur um die Gesamtverzögerung auszugleichen, die Sleep Befehle dienen dazu den richtigen Abstand zwischen 2 Noten einzuhalten.

Ich empfehle nochmal das mit Waitable Timer Objects umzusetzen. Die haben in der Regel eine viel bessere Auflösung.

Auf jeden Fall hat das mit C++ so ziemlich gar nichts mehr zu tun.

l'abra d'or

Es erzeugt Musik? Wie das? Schreibst du da ins Sound-Device? Kann es sein, dass es hier zu Staus kommt? Kann deine Karte Hardware-Mixing, oder läuft das über Software?
BTW. ist eine Abfolge von Noten noch nicht wirklich Musik. Die besteht üblicherweise aus parallel ablaufenden Tonfolgen, synchron an der Melodie orientiert (Homophon) bzw. eigentständig (Polyphon). Beides wird schwer zu realisieren mit deinem bisherigen Modell. Evtl. kannst du das optimieren (wenn du vor hast mehr als nur eine Melodie zu generieren).

Alsooo:
Es erzeugt in dem Sinne Musik als dass es zur rechten Zeit steuerinformationen an einen "Roboter" sendet der dann die Noten spielt.
Bis jetzt ist es testweise so dass statt den Steuerdaten einfach nur eine Bildschirmausgabe :"Press Note x..." kommt.
Ich mache also nichts mit Sound-Devices oder ähnliches. Das mit den parallelen Tonfolgen klappt schon ziemlich gut. Es wird eine MIDI-Datei eingelesen und daraus die Steuerinformationen generiert.

Ich arbeite nicht mit threads. DIe CPU Auslastung ist sowohl vor als auch nach dem "Ruck" bei ca 1% mit gelegentlich kurzen Spitzen auf bis zu 8% (Intel Q6600)
Auch beim Speicher kann kaum ein Unterschied festgestellt werden. Nach dem "Ruck" ist etwas mehr Cache belegt(1720 bzw 1580 von 4000 MB) und etwas weniger freier Arbeitsspeicher(1134 - 1284 MB) aber das sollte daran liegen, dass das System schon ne Stunde länger läuft.

Wenn man den Prozess anschaut benötigt das Programm nach dem "Ruck" 8000K Memory und vorher 7400K, ich denke das schwankt aber auch etwas.

Ich habe auch den Tipp beherzigt und bei jedem Event "Press Note" die aktuell verstrichene Zeit in ein Textfile geschrieben. Man kann erkennen, dass die Verzögerung nicht an einer Stelle auftritt sondern relativ linear über die gesamte Länge (mal etwas stärker mal etwas schwächer). Der Programmteil mit den Sleep Funktionen ist übrigens eine einzige große While-Schleife.

unskilled

Wie wärs denn, wenn du zu testzwecken mal die Sleeps rausnimmst?
Dann guckst du mal, ob das Problem noch besteht - dann ist das mit dem müsste, könnte, sollte endlich mal weg und man kann sagen: da liegt das problem oder aber das kann es nicht sein.

bb

Ohne die Sleeps braucht es vor und nach dem "Ruck" 2590 ms +-10ms. Es ist also kein Unterschied feststellbar. Könnte ja aber trotzdem an der Berechnung der "sleeptime" liegen und nicht an den Sleep(sleeptime) Befehlen an sich ?

Zaus

kann ich beiträge löschen wenn noch niemand geantwortet hat?

SideWinder

Nein, Beiträge kannst du hier nie löschen.

BTW: Kann es sein, dass nur die Ausgabe das Problem ist? Also das Ausgeben von Zeichen in der Konsole länger/kürzer dauert? Die Ausgabe wird nämlich gepuffert...

MfG SideWinder

Zaus

Danke, werde das mal überprüfen.
Habe jetzt mal Waitable Timer Objects statt Sleep() reingenommen, es sind aber keine zeitlichen Unterschiede messbar (bzw die Sleep()Version ist einige Millisekunden schneller).

C++ Forumbot

Dieser Thread wurde von Moderator/in Marc++us aus dem Forum C++ in das Forum WinAPI verschoben.

Im Zweifelsfall bitte auch folgende Hinweise beachten:
C/C++ Forum :: FAQ - Sonstiges :: Wohin mit meiner Frage?

Dieses Posting wurde automatisch erzeugt.

Hallo Zaus,

vieleicht hilft die Funktion:

int _set_sbh_threshold(
   size_t size 
);

weiter.

Hintergrund ist Heapfragmentierung und mehr.
Das kann passieren, wenn viele kleine Objekte auf dem Heap angelegt werden.

Viel Erfolg, Gruß Frank

Zaus

Also an der Ausgabe kann es eigentlich nicht liegen, da die ja auch in dem Test ohne die Sleep() Funktion noch drin war und es trotzdem ohne große Verzögerung lief.

zu _set_sbh_threshold:
Versteh ich das richtig, dass ich damit die Grenze setzen kann bis zu welcher Größe die Objekte im small-block heap abgelegt werden und ab welcher Größe im "normalen" heap?
Wenn ja auf welchen Wert sollte der threshold gesetzt werden? Ich erzeuge übrigens an keiner Stelle meines Code ein Objekt dem ich mit new manuell Speicher zuordne...

Gruß Zaus

Hallo Zaus,

Schau mal unter
http://msdn.microsoft.com/en-us/library/a6x53890%28VS.80%29.aspx
früher (win95, 98, nt) wurde der small-block heap
mit einer default threshold size von 1016 verwendet.
Heute (win2000++) ist der small-block heap per Default abgeklemmt.

Wir hatten so ein ähnliches Phänomen schon mal,
das Programm wurde beim nächsten Neustart deutlich langsamer,
unter Windows, unter Linux jedoch nicht.

Hat übrigends nicht direkt was new und delete zu tun.
std::string und stl container arbeiten intern auch mit dem heap.

Probier es mal, vieleicht hilft es.

Gruß Frank

Zaus

Vielen Dank für die Erklärung, werde es auf jeden Fall mal testen.
Gruß Zaus

Zaus

Leider bringt auch _set_sbh_threshold keinen Effekt.
Außerdem habe ich alle Sleep() Befehle durch waitable timer objekts ersetzt.
Auch an cout<< kann es nicht liegen, die wurden auch entfernt.

Der "Ruck" ist auch umkehbar, habe jetzt den PC angelassen und noch ein paar unbedeutende Änderung am Programm vorgenommen und auf einmal sind die Zeiten wieder wie sie sein sollten... Ich hab echt keine Ahnung an was das liegen könnte.

Zaus

Das Problem besteht immer noch. Auch auf anderem Betriebssystem, Visual Studio Version und Hardware...
Kann es sein, dass Speicher nicht wieder richtig freigegebn wird wenn das Programm beendet wird indem wärend es läuft das Fenster geschlossen wird (oder auch mit dem exit Befehl?

Danke für eure Hilfe
Gruß Zaus