enormer performance Einbruch bei PB v5.21

[captain_hesse]

Also zunächst mal würde ich es gerne vermeiden teile des Quellcodes hier zu posten da ich diesen eventuell noch kommerziell nutzen möchte, das hängt halt davon ab wie gut es mir gelingt die Spielstärke des Programms noch zu verbessern. Allerdings kommt PB in der aktuellen Version mir da ganz und garnicht entgegen ich habe in den letzten Tagen etliche Tests gemacht und was interessantes herausgefunden. Die Anzahl der Züge die das Programm untersuchen kann ist sehr stark davon abhängig wieviele Figuren auf dem Brett stehen, ist das Brett voll müssen auch viele Züge generiert und sortiert werden, stehen aber nur noch zwei Könige auf dem Brett sind nur noch wenige Züge zu generieren und garnichts mehr zu sortieren folglich müsste das Programm wenn nur noch zwei Könige auf dem Brett stehen viel schneller sein. Bei allen früheren PB Versionen ist das auch so nur bei v5.21 nicht da läuft das Programm immer gleich schnell es berechnet im schnitt ca. 600000 Stellungen pro Sekunde egal welche Stellung auf dem Brett steht während alle anderen Versionen 900000 - 1200000 Stellungen erreichen und wenn nur noch zwei Könige auf dem Brett stehen sind es sogar knappe 3 Millionen Züge die es schafft außer bei v 5.21 da sind es immer ca. 600000. Ich konnte bisher auch nirgendwo einen speziellen Programmteil finden der dafür verantwortlich ist. Es kommt mir fast so vor als ob ein delay mit drinn wäre der das ganze auf eine einheitliche Geschwindigkeit bringt. Ich glaube nicht das dafür nur ein par zusätzlich ASM Zeilen verantwortlich sind die der Compiler jetzt mehr generiert der fertige Code hat inetwa die gleiche Größe sondern eher das hier wohl ein neuer Bug in PB5.21 entstanden ist. Ich werde weiter nach der Ursache suchen allerdings habe ich immer noch keinen Schimmer wo ich den Hebel ansetzen soll

[captain_hesse]

Ok ich hab was gefunden der Zugriff ElapsedMilliseconds() dauert bei v5.21 extrem lange
hier ein Beispiel:

Code: Alles auswählen

OpenConsole()
Declare rec()
Global ti

time=ElapsedMilliseconds()
rec()
PrintN("fertig "+Str(ElapsedMilliseconds()-time))
Input()




Procedure rec()
  ti+1
  If ti<5
    For x=1 To 50
      rec()
      
      ; diese zeile bremst ohne ende   
      tt=ElapsedMilliseconds()
      ; ****************************
      
      
    Next
    
  EndIf
  
  ti-1
EndProcedure

einfach mal die angegebene Zeile zum Kommentar machen dann sieht man den Unterschied

[ts-soft]

http://www.purebasic.fr/english/viewtop ... 91#p430291

[HeX0R]

Du kannst Dir ja ein Macro an den Kopf setzen:

Code: Alles auswählen

Macro ElapsedMilliseconds()
  GetTickCount_()
EndMacro

Dann hast Du wieder das vorherige Verhalten.

Aber es kommt mir schon etwas komisch vor, dass dieser Befehl für Deine Probleme verantwortlich sein soll.
Ich meine, wie oft ruft man das wohl in einer zeitkritischen Schleife auf?

[captain_hesse]

Hab ich bereits gemacht allerdings habe ich alle ElapsedMilliseconds() durch GetTickCount_() ersetzt jetzt läuft es auch wieder so wie es soll

Ich meine, wie oft ruft man das wohl in einer zeitkritischen Schleife auf?

eigentlich genau so wie es hier in diesem Beispiel zu sehen ist aber du hast recht es bremst und ich muß mein Timerproblem anders lösen bin gerade dabei das ganze Programm zu überarbeiten.

[Thorium]

Der Overhead für QueryPerformanceCounter, welcher nun verwendet wird, ist tatsächlich größer als bei GetTickCount, was früher verwendet wurde. Allerdings befindet der sich dennoch im Nanosekundenbereich. Du verlierst die Performance also weil du unnötig oft ElapsedMilliseconds() aufrufst. Das gibt dir unter 5.20 sowieso keine millisekundengenauen Werte zurück.