i.l
StartTime = ElapsedMilliseconds()
For i = 0 To 10000000
Next i
ElapsedTime = ElapsedMilliseconds()-StartTime
MessageRequester("Stop", StrU(ElapsedTime,#lond),0)
durchlaufen lasse ist auf meinem Rechner (Pentium 3 1,4 GHz) "PureBasic 4.0 Beta" ca 10%langsamer in Bezug auf PB 3.94.
PB 3.94 brauch ca. 1000ms
PB 4.0 Beta 2 braucht ca. 1110ms
Na hoffentlich beta. Denn alles was ich bisher getestet habe, war mit der 4.0 langsamer als mit den alten PB-Versionen... und die exe-Files sind bei der 4.0 auch größer geworden....
Ist doch kein Wunder, das neue String-System ist nunmal langsamer. Das wird sich auch bis zur final nich ändern, dafür haben wir jetzt die Threadsicherheit die sich ja so viele gewünscht haben.
Was auch eine Rolle spielen könnte ist das jetzt Fred kaum noch (keine?) Procs in reinem Asm schreibt, damit er die besser auf andere Systeme portieren kann. Also freut euch auf eine langsamere Runtime, aber dafür schnellere Developmenttime von PB
Warum bremst der Ausdruck a = a (und a ist dabei 0) die Schleife so extrem ab? Wenn ich in jeder Schleife +0 addiere, geht das dreimal so schnell als wenn ich nichts mache:
a = 0
StartTime1 = ElapsedMilliseconds()
For i = 0 To 100000000
a = a + 0
Next i
ElapsedTime1 = ElapsedMilliseconds() - StartTime1
a = 0
StartTime2 = ElapsedMilliseconds()
For i = 0 To 100000000
a = a
Next i
ElapsedTime2 = ElapsedMilliseconds() - StartTime2
MessageRequester("Stop", Str(ElapsedTime1))
MessageRequester("Stop", Str(ElapsedTime2))
Das ist bei 3.94 auch nich anders. Liegt warscheinlich daran das du kurz nachdem du aus a gelesen hast wieder reinschreibst. Weiß den Fachausdruck dafür nicht mehr, jedenfalls ergibt das ein Problem für die CPU weil a noch nicht "komplett geladen" wurde. (Relativ kompliziert das ganze)
Jedenfalls wartet die CPU halt ein bisl bis die wieder in a schreibt.
Mit "+0" verhinderst du diesen Effekt. (Was auchnoch ein besonderen Fall hervorrufen kann, wodurch das ganze schneller geht. Aber will ja nich zu viel vom ASM-Kram verraten )
Das ganze kann aber auch von CPU zu CPU unterschiedlich sein.
i.l
StartTime = ElapsedMilliseconds()
For i = 0 To 1000000000
Next i
ElapsedTime = ElapsedMilliseconds()-StartTime
MessageRequester("Stop", StrU(ElapsedTime,#Long),0)
i.l
Delay(100)
SetPriorityClass_(GetCurrentProcess_(),#REALTIME_PRIORITY_CLASS)
StartTime = ElapsedMilliseconds()
For i = 0 To 1000000000
Next i
ElapsedTime = ElapsedMilliseconds()-StartTime
MessageRequester("Stop", StrU(ElapsedTime,#Long),0)
SetPriorityClass_(GetCurrentProcess_(),#NORMAL_PRIORITY_CLASS)
Gemessen auf einer AMD Maschine 240018100- XP Pro
PB 3.94 Brauch ca. 3594ms
PB 4.0 Beta 2 braucht ca. 3531ms
#REALTIME_PRIORITY
PB 3.94 Brauch ca. 3093ms
PB 4.0 Beta 2 braucht ca. 2813ms
Garnich gesehen das es nur eine einfach For-Schleife ist, ohne was drin:
Leute, das bringt nichts sowas zu messen. Der Unterschied beim messen rüht daher das die Schleifen ein unterschiedliches Offset in der Exe haben und somit der eine oder der andere JMP schneller ist. Desswegen ist es ja auch so schwer die Geschwindigkeit von ASM-Befehlen herrauszufinden. Das Offset spielt bei solchen Sachen eine große Rolle.
Alles was ihr hier rausbekommt hat nichts mit PB zu tun..
Lebostein hat geschrieben:Na hoffentlich beta. Denn alles was ich bisher getestet habe, war mit der 4.0 langsamer als mit den alten PB-Versionen... und die exe-Files sind bei der 4.0 auch größer geworden....
Kann ich nicht bestätigen. Hab ein (kleines) Programm geschrieben, dass - mit PB4B2 kompiliert - weniger Platz benötigt