![]() |
Re: "Programm-Bremse" gesucht
Ich glaube, ich muss nochmal erwähnen, dass bei dem Verlangsam-Thread der Prozess nur 1 einzige CPU verwenden darf (Stichwort: SetProcessAffinity() ). Ansonsten kann es wunderbar passieren, dass auf der einen CPU der Langsammacher läuft und auf der anderen das eigentliche Programm. So etwas sollte nicht passieren. Und es geht hier nicht unbedingt drum, verschiedene Operationen langsamer auszuführen, sondern einfach nur die Anzahl an Ausgeführten Operationen pro Zeiteinheit zu verringern. Da Windows immer die volle Last verwendet, wenn diese gebraucht wird, muss man Windows einfach sagen, dass der Rest schon durch was anderes belegt ist, und zwar hier der Langsammachthread. Das mit dem RAM-Zugriff ist nicht, um das RAM zu füllen, sondern um die RAM-Übertragungsgeschwindigkeit zu beeinflussen. Hier geht es ja auch um Bits pro Zeiteinheit. Es sollen nicht mehr Bits pro Zeiteinheit drüber, sondern weniger. Dazu muss man nicht unbedingt das RAM langsamer machen, sondern nur die Restkapazitäten voll ausreizen und dann wird der RAM-Zugriff tatsächlich langsamer, weil schon genug Müll drauf und wieder runter geht.
Wie ist denn die Idee, den virtuellen RAM so knapp zu machen, dass Windows generell auf die Festplatte auslagern muss? Bernhard PS: Das mit den zeitgesteuerten Screenshots finde ich nicht gut, weil zuerst fertig gezeichnet wird und erst dann der Screenshot aufgenommen wird. Es geht ja darum, Probleme während des Zeichnens zu finden und nicht danach. |
Re: "Programm-Bremse" gesucht
Zitat:
Bandbreite zwischen RAM und CPU ist auch meist en masse vorhanden, ebenso zwischen HDD und CPU (zu diesem Punkt noch was weiter unten). Diese ganzen Punkte sind einfach Hardware-bedingt vorhanden. Und sowas effizient per Stück Software wie gewünscht ausblenden oder sonst was damit machen, halte ich für echt nicht sinnvoll(!) machbar. Zitat:
Zitat:
Ich lasse mich echt gerne vom Gegenteil überzeugen, aber die Entwickler der heutigen Software und Hardware werden sich wohl Gedanken gemacht haben, sodass mehrere Programme nebenher einigermaßen gleich schnell laufen. Und je neuer die Hardware, desto schneller sollte es (in den meisten) Fällen sein, auch wenn man da Threads und was weiß ich noch alles einbaut... |
Re: "Programm-Bremse" gesucht
Zitat:
Und falls es hier beim TE um potenziell sichtbare "Glitches" während des Zeichnens geht, aber nach getaner Arbeit alles gut ausschaut: ![]() |
Re: "Programm-Bremse" gesucht
Moin, Moin.
Ich möchte mich bei allen Beteiligten für die interessanten Beträge bedanken. So wie Weltreiche entstehen und wieder vergehen, hat sich nun auch der Gedanke des "Nutzlos-Threads" in Luft aufgelöst. Ich werde nun, wie mehrfach vorgetragen, einfach mein altes Notebook für derartige Tests verwenden :-D |
Re: "Programm-Bremse" gesucht
Es kommt ja immer darauf an, was du genau testen willst.
Einiges kann man ja auch innerhalb der Anwendung, über ein paar Sleep oder kleine Schleifchen, ausbremsen. Also wenn es nur um ein paar bestimmte Stellen geht. Oder wenn man wissen will, wo in einem bestimmten Code die meißte Zeit verloren geht, dann erstelt man sich halt ein Zeitprofil (Zeiten zu messen sollte nicht das Problem sein) |
AW: "Programm-Bremse" gesucht
Auch wenn der Thread nun über 2 Jahre alt ist möchte ich etwas dazu beitragen.
Bei der Gelegenheit möchte ich mich bei allen hier bedanken. Ich konnte hier sehr viele nützliche Tipps finden. Ich hatte auch das Problem ein Programm ausbremsen zu müssen (Videoencoder), da, insbesondere in den Sommermonaten, mein PC beim stundenlangen encoden viel zu heiß wurde. Abgesehen davon wurden andere Programme ausgebremst. Ich nutze BES – Battle Encoder Shirase und es funktioniert einwandfrei. ![]() Vielleicht hilft es ja dem einen oder anderen. |
AW: "Programm-Bremse" gesucht
Nicht getestet, weil ich von sowas eigentlich nicht so viel halte -.-
![]() |
Alle Zeitangaben in WEZ +1. Es ist jetzt 01:30 Uhr. |
Powered by vBulletin® Copyright ©2000 - 2025, Jelsoft Enterprises Ltd.
LinkBacks Enabled by vBSEO © 2011, Crawlability, Inc.
Delphi-PRAXiS (c) 2002 - 2023 by Daniel R. Wolf, 2024-2025 by Thomas Breitkreuz