PureBoard

Hallo,

seit über 14 Jahren setzte ich Purebasic fast täglich im Beruf und Zuhause ein. Eine wirklich tolle Sprache.
Zur Zeit verwende ich immernoch die PB Version 5.24. Hin und wieder habe ich die neueren Versionen getestet.
Was mir aufgefallen ist, ab der PB 6.x sind die erstellen Exe-Dateien viel langsamer.
Ich kann den Sourcecode leider nicht posten. Er umfasst über 21000 Codezeilen.
Wen ich den gleichen Code mit der PB 5.24 kompalieren benötigt die Exe für die Aufgabe ca. 30 Sekunden.
Das Gleiche mit PB 6.03 um 45-50 Sekunden. Das sind ca. 50% Geschwindigkeitsverlust.
Das Programm bearbeitet Strings und zwischendurch Dateioperationen. Also nichts großartiges.
Kann jemand das gleiche Verhalten bestätigen ?

Liebe Grüße
Lite

Ohne genauer welche Operationen durchgeführt werden kann man das nicht so genau sagen woran es liegt.
Kann mir aber vorstellen das es an mehr Überwachung und Auswertung von internen Funktionen und neuen ASM compiler liegen kann.

- Als X86 oder X64 Kompiliert.
- Internen Aufruf anderen OS API Funktionen.

Könnte vielleicht mit dem neuen C -backend ab Version 6.00 zu tun haben.
Added: a new C backend compiler for all PureBasic versions.
C ist anscheinend doch nicht so schnell, wie ASM. Die Unterschiede sind aber auch
nur marginal.

Ich habe auch noch die Version 5.61 installiert, da ich mir damals nicht so sicher war.
Und für mich neue gravierende, interessante Funktionen gab es bisher auch nicht.
Das betrifft auch die Bug-Beseitigungen.

Solange keine Top-Neuerungen, die mich interessieren, dabei sind, behalte
ich diese ältere Version auch noch bei.

Na ja, der C-Compiler ist by default gar nicht aktiviert, aber ich denke schon, dass der mit PB5.24 locker mithalten könnte.
Wenn denn die Optimierung in den Compileroptionen auch angehakt ist.

Verwende hauptsächlich den x86 Compiler, auch in diesem Fall und der Debugger ist aus.

Der Schritt von PB 5.24 nach PB 6.0 ist ja schon ein ziemlich großer, da liegen immerhin 9 Jahre dazwischen.
Du kannst im PB-Museum auch die Versionen dazwischen noch immer runterladen und mal mit denen Kompilieren.
Dann siehst du vielleicht besser, ab welcher Version oder mit welchem Update diese Geschwindigkeitsabnahme kam.

Generell ist es aber nicht ausgeschlossen, dass mit einem Update ein Programm langsamer läuft, wenn z.B. ein Bug gefixed wurde, der zu Memory-Leaks oder Abstürzen geführt hat und nun durch eine zusätzliche Routine behoben wurde.

Warum muß der gesamten Quellcode in EINE Datei PureBasic.obj zusammen gequescht werden? Was wäre wenn nur noch der geänderten Teil in jeweils eine OBJ-Datei compiliert würde um lästige Wartezeit zu sparen? Der Linker würde sich dann um die vielen OBJ-Dateien kümmern.

H.Brill hat geschrieben: 11.11.2023 16:26 Könnte vielleicht mit dem neuen C -backend ab Version 6.00 zu tun haben.
Added: a new C backend compiler for all PureBasic versions.
C ist anscheinend doch nicht so schnell, wie ASM. Die Unterschiede sind aber auch
nur marginal.

Damit liegst du komplett daneben. Natürlich ist das C-Backend um Welten schneller. Immerhin haben in den C-Compiler ganze Entwicklerteams ihre Zeit investiert um zu optimieren, was optimierbar ist. Das ASM-Backend von Fred mit dem Peephole-Optimierer kann da kein bisschen mithalten. Das schreibt Fred auch selbst im Blog, siehe hier: https://www.purebasic.fr/blog/?p=502

Meine Vermutung zum Thema ist die Umstellung von Ascii auf Unicode per Default. Da lite offensichtlich viel mit Strings arbeitet, kann das etwas ausmachen, wenn per Zeichen zwei Bytes statt nur einem benutzt werden.

Wenn Textdateien (Ascii oder UTF8) eingelesen werden, werde diese intern nach Unicode gewandelt.

Ja mir scheint auch die Executables werden bei jeder größeren PB Version etwas mehr aufgebläht und etwas langsamer. Liegt das bei den Strings am Unicode Format? Wenn die Strings 2x so viel Speicher benötigen kann das auch etwas die Performance drosseln beim Alloziieren / Kopieren etc.

Du solltest bei PB 6 Executables immer "optimize Code" ankreuzen; in der Regel ist der C Compiler mehr up-to-date mit Optimierungen, meine Programme sind mit C Backend im Durchschnitt 3 mal schneller als Assembler Backend, und manchmal sogar noch schneller.

Ich habe aber eher den Eindruck, daß es irgendwo im Assembler Backend klemmt. Kann nicht genau darauf deuten aber so einige Sachen sind unverständlich langsam wie z.B. auf ein Array zugreifen.