PureBoard

ts-soft hat geschrieben:@Mok
So ein blödsinn fehlte bisher noch

Hä?!
Dass MessageBox_() kleinere Executables erstellt, sollte schon bekannt sein.
Bezüglich GetFileSize_() hab ich einen kleinen Test durchgeführt:
(Ich weiss, dass ElapsedMIlliseconds() nicht das genaueste ist, aber das Ergebnis zeigt schon deutliche Unterschiede) Das Ergebnis: Ich hab schon viel Schmarren verzapft, aber meine eigenen Tests kenne ich fast auswendig.

Edit 1: Kann man nicht einfach mal was sagen, ohne von jeder Seite verarscht zu werden?
Edit 2: @c4s: Ach wirklich? Stell dir vor, das habe ich auch gewusst. Da FileSize() aber auch eine Möglichkeit bietet, die Dateigrösse festzustellen, hat es nunmal beim Test mitgemacht!
Edit 3: Ok, meine Aussage über MessageBox_() hat nichts mit Geschwindikeit zu tun! Dennoch ist der Befehl aufgrund der Grösse des Endproduktes vorzuziehen. Ist jetzt nicht die Welt, aber trotzdem...

Ich hab grad kein PB zur Verfügung, deshalb kann ich es nicht selbst testen, aber hast du mal getestet ob sich was ändert wenn du den letzten Code an den Anfang setzt?

@Mok
Stell mal die Reihenfolge Deines Testes um, der letzte wird wohl immer gewinnen
Und was hat kleinere Executable mit Geschwindigkeit zu tun?

Ich sag, Birnen mit Äppel vergleichen. Glaub mal weiter an den schmarrn, soll mich
nicht jucken. Muss niemanden überzeugen.

Wer weiß wie viele schlechtere Funktionen deswegen schon einen Speedtest gewonnen haben...
Woran kann das liegen? Die Ergebnisse sind reproduzierbar wenn man es wieder umdreht.

@SebastianJu2: Ich habe mit der Reihenfolge etwas herumjongliert und mit verschiedenen Einstellungen (Debugger, Skins Support) getestet, aber das Resultat bleibt das selbe: GetFileSize_() ist das schnellste, dicht gefolgt von Lof(), dann kommt lange nichts, dann kommt FileSize().
Ist halt so.

Edit:
@ts-soft: Über die Grösse des Endproduktes habe ich mich schon in meinem vorigen Posting geäussert. Glaub du lieber weiter, dass du immer Recht hast!
@ts-soft, @SebastianJu2: Ich weiss ja nicht, was ihr rumgefuhrwekt habt, aber bei mir ist es komplett egal, welche Reihenfolge das ganze hat. Setze ich GetFileSize_() and die erste Stelle und FileSize() an die letzte, ändert sich nichts! Falls es bei euch anders sein sollte: Herzlichen Glühstrumpf!

@Mok

Ok... ich hatte das nur bei einem Test von mir mal gemerkt. Kann ich mir nicht wirklich erklären. Wenn es mit dem Speicher zu tun hätte dann sollten die tausende Loops aber ausreichen um da Platz zu schaffen schon im ersten Codeteil. Von daher keine Ahnung was das ist.

Selbst mit dem Orginalcode ist FileSize am schnellsten. Jedenfalls bei mir, ist auch
logisch. Lof öffnet ja erst die Datei, wird immer am langsamsten sein.

Aber ist vollkommen egal, so was führt keiner in einer schleife 10000x aus.
API oder PB-Funktion zum Speedtest ist schon falsch. PB nutzt die API.

Runtimefunktionen, also Datenverwaltung im Speicher, z.B. Strings usw.
da kann man Zeitsparen, da macht es auch Sinn.

Eure Tests haben ja mit Speedtest nicht viel am Hut, weil man da sowieso
fast nichts rausschlagen kann, was irgendein Mensch jemals in einer
Anwendung bemerken könnte. Solche Tests wie die von Mok sind selber
nur Zeitverschwendung.

//edit
Lof() verwendet man ja auch nur, wenn die Datei sowieso offen ist, und dann ist
es das schnellste, ansonsten natürlich das langsamste. Paßt also garnich in den
Vergleich, ist wieder ein Birnen Äpfel vergleich.

@ts-soft:
Dass das keiner 1000x in einer Schleife ausführt, hoffe ich docheinmal schwer. In meinem Speedtest ging es darum, die Unterschiede zu verdeutlichen, weil man aus 1x ausführen der Befehle per ElapsedMilliseconds() immer 00 zurückbekommt. Aber lassen wir die beknackte FileSize mal beiseite.
Bevor man mit sowas hirnrissigen anfängt und um Millisekunden geizt, sollte man sein Programm eher hinsichtilch Pointer optimieren (oder zumindest lohnt es sich da eher aus), da muss ich dir wohl zustimmen .

Dieser Test macht keinen Sinn, denn die Hauptzeit die dieser Befehl benötigt besteht darin, im Dateisystem nachzusehen ob es diese Datei überhaupt gibt bzw. sie zu öffnen. Solche Anfragen werden wegen ihrer Dauer vom Betriebssystem gecached. Mehrfach die selbe Datei zu testen gibt also keinen Sinn. Das ist ungefär so als wenn man seine Internetverbindung testen will indem man immer wieder ein Bild aus dem Browsercache lädt

Grundsätzlich:
Man kann nicht PB mit C/C++ vergleichen, weil es für C/C++ hunderte verschiedener Compiler gibt. Also wenn dann bitteschön einen Vergleich mit einem konkreten Compiler. Genausowenig kann man zwei Sprachen allgemein vergleichen, weil die Anwendungsgebiete viel zu groß sind. Wenn dann kann man allerhöchstens Aussagen bezüglich eines bestimmten Algorithmus treffen.

Letztlich ist ein "langsames" aber korrektes Programm ein vielfaches mehr wert als ein "schnelles", das an jeder Ecke abstürzt. Also macht euch lieber Gedanken wie man fehlerfreie Programme schreibt, anstatt euch zu fragen wie man noch irgendwo 10ns einsparen kann

Die eigentliche Antwort auf diesen Thread wurde schon am Anfang gegeben :
http://www.purebasic.fr/german/viewtopi ... 41#p287441

Ich finde es immer wieder interessant, das "Sprachen" in ihrer Geschwindigkeit verglichen werden, also somit deren Paradigma wenn man die Frage ganz genaue nehmen würde.

Die Geschwindigkeit hängt nicht von der Sprache ab, sondern vom Compiler wie er den Code interpretiert und sodann in ASM (was via PB sodann an FASM weitergereicht wird) oder direkt in Maschinencode umsetzt. Und genau da bestehen selbst zwischen diversen Compilern gleicher Sprachen markante Unterscheide. Vergleiche mal die Geschwindigkeit eines C++ Kompilats aus VS C++ 6 und aus VS C++ 8 oder neuer. Hier merkt man die Optimierung und den dadurch entstandenen Geschwindigkeitszuwachs beim finalen Kompilat.

Der PB-Compiler ist eben nicht optimierend und daher kannst du noch soviel am Ende im nativen PB Code mit z.B. Pointern o.ä. optimieren, aber solange die Interpretation in den ASM Code eben noch nach Optimierung ruft hängt eben ein Kompilat von PB dem eines MSVS oder Intel oder GCC Compilers noch hinterher. DiIes merkst Du z.B. bei For/Next Schleifen, so auch in jenem zitierten FlipBuffers-Code-Workaround am Anfang dieses Threads, wo eben jene Routinen von PB-Nativ bis hin zu ASM direkt verfasst verglichen werden. Selbst wenn du "innerhalb" der For/Next Routine alles in ASM verfasst, hängst du der For/Next Routine in kompletter ASM Schreibe geschwindigkeitsmäßig merklich hinterher.

Und gerade Videobearbeitung wo komplette Pixelarrays via Schelifen behandelt werden, lassen ein PB Kompilat verglichen zu einem GCC Kompilat enorm in die Knie gehen. Beweis: http://www.purebasic.fr/english/viewtop ... =7&t=27449
Dort hat Trond ebenso gezeigt, wie eine native ASM Umsetzung die Sache richtig rennen lässt.

Wenn Du also mit PB maximale Performance erreichen willst (wo dann frecherweise gesagt nur noch FASM der Flaschenhals wäre ), dann kommst du nicht um eine "Bastard"- also Hybride-Codierung aus PB und ASM herum.

Aber ich denke es ist eigentlich auch nicht das Ziel von PB als eine der schnellsten Sprachen da zu stehen, eher als eine schnell erlernbare und überschaubare, daher ist dies auch keine Kritik meinerseits an PB

EDIT: Sehe Gerade Freak hat auch schon geposted ...daher sorry für Doppelungen