Kaeru Gaman hat geschrieben:meiner erfahrung nach ist PB bei schleifen und ifs (fast) immer etwas schneller,
da ein schlankerer ASM-Code erzeugt wird.
AndyX hat geschrieben:(vielleicht auch schnellste) Sprache die ich kenne
hardfalcon hat geschrieben:PB ist auf jeden Fall schneller als VB!
Das haben schon einige Leute in der Praxis getestet, so z.B.
zwischen mehreren C-Compilern, VB und PB.
PB belegte immer den letzten Platz, VC++ war meist der
Gewinner, die anderen C-Compiler und VB dazwischen.
Diskutiert wurden die Ergebnisse damals im Chat und im
englischen Forum, inkl. den entspr. Testcodes.
Ich habe keine Lust das nochmal durchzukauen - aber bitte
erzählt nicht "einfach so" das PB das Beste ist (speziell hardfalcon & Co.).
Bei solchen Tests ist es meist genau das Gegenteil.
PB könnt ihr ja trotzdem weiterhin verwenden, auch wenn es
bei einem PaarMillionen-Schleifendurchlauf mal 500ms langsamer ist.
Auch wenn ihr PB verehrt: bleibt bitte in der Realität... denn gegenüber
wissenden Menschen macht Ihr Euch mit solchen Aussagen nur lächerlich.
freedimension hat geschrieben:Mit PokeB und PeekB wird das eher nicht schneller da diese noch den Funktionsüberhang mit sich schleppen.
Besser richtig mit Pointern arbeiten
Da sage ich nur: Vorsicht, bei dieser Aussage!
Du gehst hier von Allgemeinwissen aus, da Pointer in so gut
wie jeder anderen Sprache schneller sein sollten - da die Funktionen
Peek & Poke aufgerufen werden und wieder zurückspringen.
In der Praxis sieht das bei PB allerdings etwas anders aus:
Da kann man nicht von solchem Wissen ausgehen, sondern
muß es immer testen, je nach Anwendung.
Ich hatte schon ein Beispiel, da waren Peek&Poke schneller als
Pointer, da der erzeugte Pointer-ASM-Code von PB nicht gerade
zum jubeln ist. Ich war damals auch sehr erstaunt (da eig.
theoretisch unmöglich), aber als ich mir dann den ASM-Output
angeschaut habe war es auch klar.
Damals wollte ich einen Peek/Poke-Code aus dem Forum
(glaube von Sylvia) mit Pointer optimieren - war also reiner
Zufall.
Also besser immer erst testen. Je nach Schleife und Anwendungsform
_kann_ es mit Peek/Poke auch schonmal schneller sein.
Nur mal im Kopf behalten, und wenn das nächste mal gebraucht,
dann selbst testen...
Schlechter (generierter) ASM-Code ist immernoch langsamer als
guter/optimierter (generierter) ASM-Code.
. Die Datei operationen sind verdammt langsam! Zum Glück gibt es aber die FastFile Lib
Aber egal, ich habe da eh (noch) zuwenig Ahnung... 
)
) an...
