Programm wird langsamer
-
Nach mehrfachen Suchen in dem Fred hier habe ich noch keine Zeile Code von einer
zentral wichtigen Stelle gefunden.
Was auch immer du tust, so hilft vielleicht eine Ausgabe in eine Datei z.B.
einzelne Zeiten an bestimmten Stellen. Eine Minute unterschied die durch Sleeps zustande kommt? ... Müssen aber viele Sleeps sein
du hast nicht zufällig eine
if-Bedingung irgendwo drin mit Sleep(60000) in die er reinspringt?
-
Warum genau hast du die Sleep()-Aufrufe im Programm? Ich glaube dir fehlt für dein Vorhaben ganz einfach die Erfahrung in den Bereichen:
MfG SideWinder
-
- Nein ich hab nirgendwo ein Sleep(60000)
- Wozu brauch ich jetzt das Wissen über Echtzeitbetriebssysteme wenn das Programm gerade nur unter Windows7 läuft
- Dass mir die Erfahrung beim Scheduling oder mit Profilern fehlt bestreite ich nicht, deshalb bitte ich ja auch um Hilfe.
- 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 hab keine Ahnung an was sowas grundsätzlich liegen könnte also bitte was für Codeteile soll ich posten? Ich bezweifel ja, dass dieser große Unterschied nur durch die Sleep-Befehle kommt aber ich weiss es nunmal nicht...
- Am Einlesen der Dateien kann es nicht liegen, da ich alle Informationen vor dem eigentlich starten in einem vector speichere und dann während der Zeitmessung nur damit arbeite
- Wie gesagt manchmal machts nen "Ruck" und das Programm ist fortan 20% langsamer, wenn ihr mir sagt welche Codeteile ich posten soll mach ich das gern.Gruß Zaus
-
Arbeitet das Programm mit threads? Wie sieht die Prozessorauslastung vor und nach dem "ruck" aus und wie verhält sich der Speicher?
Alles so Dinge die verantwortlich sein _könnten_, das eingrenzen musst du übernehmen... Entsprechend mal kundig-googlen was ein Profiler ist und wie man ihn verwendet. Oder aber das Programm mal durchsteppen, und schaun, ob irgendwo was gemacht wird was du nicht willst, bzw. mal alle Schleifen und Bedingungen auf Richtigkeit prüfen, etc.
-
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.
-
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.
-
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 ?
-
kann ich beiträge löschen wenn noch niemand geantwortet hat?
-
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
-
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).
-
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
-
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
-
Vielen Dank für die Erklärung, werde es auf jeden Fall mal testen.
Gruß 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.
-
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
