Anregungen und Vorschläge zu PROFAN
Hier können Vorschläge für künftige PROFAN-Versionen, Ausgestaltung der PROFAN-Seiten und -Foren, etc. gemacht werden.

| Suchen
Seiten: 1 2 | Zurück zur Übersicht

Autor | Thema: Optimierung von Variablennamen
Stefan Stroehlein
| Datum:23.03.02 09:33 (eMailTo@StefanStroehlein.de) |
Wenn schon kein Nativecode erzeugt wird, dann sollten wenigsten beim compilieren die Variablennamen gekürzt werden. Ein Variablennamen mit einem Zeichen (zB 'X&') wird 30% schneller verarbeitet wie ein Variablenname mit zwanzig Zeichen. Gerade bei größeren Programmen braucht man aber nun mal vernünftige Variablennamen und die sind halt länger wie ein 'x&'.
Frank Abbing
| Datum:23.03.02 10:40 (frankabbing@12move.de) |
Hallo Stefan, du kannst dir vielleicht selber helfen, indem du dir einen Pre-Compiler schreibst, der in deinen Text vor dem Compilieren die Variablennamen abändert. Du brauchst ja den Pre-Compiler nicht jedes mal zu benutzen, nur wenn dein Programm fertig ist und du es als Exefile erstellst. Gruß, Frank
Stefan Stroehlein
| Datum:23.03.02 11:26 (eMailTo@StefanStroehlein.de) |
Hallo Frank, daran habe ich auch schon gedacht. Allerdings ist es nicht nur ein Programm sondern insgesamt 10 Programme die sich dazu noch gemeinsame Inc-Dateien teilen. Zum anderen muß ich, je nach dem was sich unsere Damen im Büro so wünschen, diese Programme ständig erweitern und bestehende Bugs beheben. Ausserdem müßte man bei einer Programmiersprache die in der Version 7.5 vorliegt so eine grundlegende Codeoptimierung vom Compiler erwarten können. Auch an anderer Stelle sollte tunlichst an der Performence gefeilt werden. Irgend wie erinnert mich das alles an die guten alten C64 Basic-Zeiten. Bei dem man sich jeden Befehl 10 mal überlegen mußte ob er nicht zu gunsten der Perfomence weggelassen wird. Allerdings hatte der nur eine Taktfrequenz von 800Hz und nicht wie heutige Rechner 800.000.000Hz.
Frank Abbing
| Datum:23.03.02 17:07 |
Hallo Stefan, du hast recht, Performance ist wichtig. Ich meinte auch einen Pre-Compiler, der individuell arbeitet und einen neuen Text mit neuen Variablennamen im Temp-Verzeichnis erzeugt und das dieser neue Text dann compiliert wird. Oder gibt's so ein Programm schon ? Ich wäre evt. bereit, so ein kl. Progrämmchen zu schreiben, wenn genug Interesse besteht und ich mal Zeit hierzu habe... Gruß, Frank
Rene Wagner
| Datum:23.03.02 18:32 (apollo@rw-net.de) |
Hallo Frank, ich denke Interesse besteht schon, wenn es sich tatsächlich so stark auf die Performance auswirkt. Vielleicht kann Roland auch noch etwas dazu sagen (im Vorausblick auf Profan 8.0 ;) ). mfG, René
Roland G. Hülsmann
| Datum:24.03.02 19:28 (rgh-soft@t-online.de) |
> Vielleicht kann Roland auch noch etwas dazu sagen (im Vorausblick auf Profan 8.0 Ja ich kann etwas dazu sagen. Ich arbeite schon länger an entsprechenden Routinen, bin aber bisher noch zu keiner wirklich tragfähigen Lösung gekommen. Es ist aber durchaus möglich, daß ich spätestens zur Version 8 eine Lösung habe. Gruß Roland
Jörg Sellmeyer
| Datum:23.03.02 19:09 (joerse@gmx.de) |
Hallo, >>Oder gibt's so ein Programm schon ? Tatsächlich gibt's so ein Programm schon. Man mag es ja gar nicht sagen - aber in PrFellow gibt es so ein eingebautes Optimiertool. Es wäre schön, wenn Thomas Hölzer entweder sein zu Weihnachten angedeutetes letztes Update verwirklichen oder seine Lizenzbestimmungen etwas lockern würde b. z. w. PrFellow wieder zum Download zur Verfügung steht. Sonst muß sich eben tatsächlich jemand daran machen und etwas schreiben. Schönen Gruß Jörg
Sven Schmidts
| Datum:24.03.02 13:50 (schmidts@flat2serv.de) |
Hallo, ich habe seinerzeit mal mit dem Tool vom TEH rumprobiert, es hat unheimlich viel gebracht, allerdings bei mehreren Zeilen bzw. entsprechend viel Variablen. Die Programme waren teilweise 20% schneller. Es bringt einiges, den Code erst nach unnötigen Variablen zu durchsuchen (im Prf-Pad die Option "Optimieren" im Setup aktivieren oder per Hand aufrufen) und lange Variablenbezeichner (> 5 Zeichen) zu kürzen. So problemlos funktioniert das mit dem Tool von TEH leider nicht, ich hatte mit der automatisch teilweise Abstürze ... und den Fehler bei > 30000 Zeilen zu suchen hatte ich auch keinen Bock. Mfg. Sven Schmidts
Sven Schmidts
| Datum:24.03.02 19:33 (schmidts@flat2serv.de) |
@Stefan: Eine automatisierte Optimierung ist ein heikles Thema, daher haben wir es im PrfPad nicht drin (machbar wäre es, keine Frage). Wenn Du das PrfPad benutzt, dann solltest Du im Setup die Optimierung aktivieren. Dann bekommst Du zahlreiche Optimierungstips ... Standart-mässig ist die, glaube ich, nicht aktiviert. Es lohnt sich aber durchaus. @All: Das Thema "PreCompiler" hatten wir schon einige Male, der Compiler müsste sich aber mindestens zweimal durch den Source durchackern, was länger dauert (warum auch immer ...). Ich denke, eine Option für den Compiler wäre nicht schlecht, so wie $P bzw. *P. Durch die wird dann entschieden, ob eine Variablenoptimierung (2-path-compiler) vorgenommen wird oder so wie bisher "compiliert" wird. Mfg. Sven Schmidts
Stefan Stroehlein
| Datum:25.03.02 17:07 (eMailTo@StefanStroehlein.de) |
Ich habe eine DLL geschrieben die ein Profan²-Programm optimiert. Max 30.000 Programmzeilen Max 10.000 Variablen Max 10.000 Proceduren Ein 800Mhz Rechner braucht für ein Programm mit 5000 Zeilen ca. 2 Sekunden. Nach dem precompilieren sind die Programme nur noch halb so groß. Der DLL brauch nur der Name der Datei übergeben werden. Die precompilierte Datei wird dann mit gekürzter Endung zurück geschrieben. zB Orginal "C:\PROFAN\TEST.PRF" Precombilat "C:\PROFAN\TEST.PR_" Wer interesse hat soll mir mailen.
Sven Schmidts
| Datum:26.03.02 08:22 (schmidts@flat2serv.de) |
Vielleicht eine blöde Frage, aber was genau wird optimiert? Ich meine, kürzt Du Variablennamen? Schau Dir mal die Optimierung vom Prf-Pad an, die kann ebenfalls einiges, nur wird der Anwender halt drauf hingewiesen und es nicht automatisch erledigt. Würde mich mal interessieren, die DLL. Gerade im Hinblick auf das Prf-Pad (Plugin oder so). Mfg. Sven Schmidts
Stefan Stroehlein
| Datum:26.03.02 10:59 (eMailTo@StefanStroehlein.de) |
Hallo Sven, ich habe einmal folgendes Beispielprogramm benutzt. Orginal Sourcecode: 98.012 Byte Precompilat: 59.701 Byte -------------------------------- Differenz: 38.311 Byte Orginal Sourcecode compiliert: 72.055 Byte Precompilat compiliert: 47.110 Byte ------------------------------------------ Differenz: 24.945 Byte Nach dem Profan² auch im copilierten Programm eine Interpretersprache bleibt, dürfte der Geschwindigkeitsvorteil eindeutig beim kleiner Programm liegen. In wie weit dürfte von Fall zu Fall unterschiedlich sein. PrfPad weist nur auf nicht benutzt Variablen hin, wobei die Angaben mit Vorsicht zu geniesen sind. So habe ich für Variablen eine Melung erhalten bei denen ich mir sicher bin das sie verwendet werden. Zu Deiner Frage was das Programm macht: Es kürzt nicht nur Variablen sondern nimmt sich auch die Procedurnamen vor, lösche unnötige Leerzeichen usw. Zum Thema Plugin: Ich stelle die Dll als Freeware zur Verfügung, was daraus gemacht wird ist mir egal.
Sven Schmidts
| Datum:26.03.02 12:18 (schmidts@flat2serv.de) |
In der neuesten Version wurde die Variablenoptimierung ein wenig geändert. Ansonsten wäre ich mit der Optimierung sehr vorsichtig. Ein "Trim" der Befehlszeilen wird schon vom Compiler erledigt, Leerzeilen dürfen nicht entfernt werden (sonst stimmt die Zeilennr. in ev. Fehlermeldungen nicht mehr). Bin aber gespannt drauf, habe complexe Test-Quelltexte mit > 30000 ;) Mfg. Sven Schmidts
Roland G. Hülsmann
| Datum:26.03.02 12:30 (rgh-soft@t-online.de) |
Hallo Stefan (und die anderen Leser), damit nicht unnötiger Aufwand betrieben wird, beschreibe ich mal kurz, was der Compiler selbst an Optimierungen schon macht (und daher nicht optimiert werden braucht): - Kommentare werden restlos entfernt. Lediglich ein Platzhalter für eine Leerzeile bleibt übrig. Das gilt auch für Leerzeilen, damit die Zeilennummern bei Fehlermeldungen den tatsächlichen Zeilennummern im Quellcode entsprechen. Die Geschwindigkeit wird von diesen Platzhaltern nicht beeinflußt, lediglich ein wenig die Größe des Compilates. - Leerzeichen werden entfernt. - Funktionen (DEF) und Prozeduren (PROC) werden in ihre Adressen aufgelöst. D.h. z.B. ein Optimieren der Prozedurnamen bringt exakt nichts, da diese im Compilat nicht mehr vorkommen. Da die direkten Adressen verwandt werden, ist auch die Größe des Compilates nicht von Bedeutung, da nicht nach Sprungmarken etc. gesucht wird. (AUSNAHME: GOTO und GOSUB - da wird nichts optimiert, die sind langsam ... und werden eh nicht mehr unterstützt!) - Und dann wird natürlich auch compiliert, d.h. Befehle und Funktionen in Tokens umgewandelt, etc. und der der so erzeugte Zwischencode in die PRC-Datei geschrieben. Gruß Roland
Stefan Stroehlein
| Datum:26.03.02 14:32 (eMailTo@StefanStroehlein.de) |
Hallo Rolan, Tatsache bleibt aber das eine Variable mit einem Zeichen ca. 30% schneller verarbeitet wird als ein Varaible mit 20 Zeichen. Du kannst Dir sicher vorstellen das ein Programm mit ein paar 1000 Zeilen nicht besonders wartungsfreundlich wäre wenn man überall nur a& und x% verwenden würde. Deshalb habe ich diesen Precompiler gemacht. Zum entfernen von Bemerkungen usw die vom Compiler durchgeführt werden ist es doch sehr verwunderlich das ein precompiliertes Programm ca. 40% kleiner ist als ein normal compiliertes Programm. Aber wie gesagt es geht eigentlich um den Geschwindigkeitszuwachs bei der Verarbeitung von Variablen. Und um die Geschwindigkeit eines Profan Programmes steht es nicht besonders rosig. Ich hatte den Precompiler als erstes in Profan geschrieben, doch bei dessen Ausführung hätte man bequem Kaffeetrinken gehen können. Die Dll ist mit PowerBasic geschrieben, sie erledigt die selbe Arbeit innerhalb weniger Sekunden.
Roland G. Hülsmann
| Datum:26.03.02 20:44 (rgh-soft@t-online.de) |
Hallo Stefan, das mit den Variablen habe ich ja auch nicht bestritten. da macht es in der Tat Sinn und Deine DLL scheint mir in der Tat eine tolle Lösung zu sein! Gruß Roland
Norbert Spörl
| Datum:26.03.02 22:13 (nsp_ware@t-online.de) |
Ich verfolge mit Interesse diese Diskussion. War mit noch gar nicht bewußt, daß die Länge bzw. Kürze der Variablen sich so stark auswirkt. Darum würde ich Stefans DLL auch gern einsetzen. Ein anderer Aspekt ist doch sicher auch der, daß Möchtegern-Crackern mit gekürzten bzw. nichtssagenden Variablennamen das Leben schwerer gemacht wird. Und dann habe ich da noch einen Anwendungsfall, den ich mit so einer DLL gern mit erschlagen haben würde. Ich meine so eine Art bedingte Compilierung. Also Quelltext, der je nach Schalter mit oder nicht mit compiliert wird. Es wäre schön, wenn die Precompiler-DLL schalterbedingt Quelltext-Stellen entfernen könnte. '<NoComp=1> Code ... Code ... '<BeginNoComp Code .... Code .... 'EndNoComp> Code ... Code ... Trifft der Precompiler auf einen Kommentar <NoComp=0, so würde dies heißen, daß die Codezeilen zwischen den Kommentaren <BeginNoComp und EndNoComp> im Quelltext verbleiben, bei <NoComp=1> würden sie dagegen vom Precompiler entfernt werden. Eigentlich müßte so eine Funktionalität vom Compiler und Interpreter mit direkten Befehlen unterstützt werden. Bis dies aber einmal Funktionsumfang von Profan sein wird, was ich mir sehr wünsche, ist so ein Precompiler der richtige Platz dafür. Ansonsten wünsche ich mir noch, daß Du Stefan und Du Roland bezüglich Precompiler zusammen geht. Grüße Norbert
Sven Schmidts
| Datum:27.03.02 08:27 (schmidts@flat2serv.de) |
Der Editor kennt diese Bedingungen bereits, allerdings kann derzeit "nur" die Optimierung aktiviert / deaktiviert werden, da die Bedingungen vom Compiler bearbeitet werden müssen. Ein PreCompiler ist durchaus nett, muss aber auf Dauer vom Compiler mit erschlagen werden. Dann würde ich auf das DEFINE Konzept zurückgreifen, allerdings mit '{}, damit es abwärtskompatibel ist: '{$DEFINE Test} ... '{$IFDEF Test} bzw '{$IFNDEF} ... '{$ELSE} '{$ENDIF} Nicht vergessen werden darf Profan² selbst. Es müssen also direkte, vordefinierte DEFINES vorhanden sein: - PrfVersion (Profan² Version, z.B. Ver7 oder Ver8) - WIN32, LINUX usw. '{$IFDEF WIN32} ' Windows '{$ELSE} ' Linux '{$ENDIF} Natürlich müsste das schachtelbar sein, also mehrere IFDEF's hintereinander. Mfg. Sven Schmidts
Stefan Stroehlein
| Datum:27.03.02 09:24 (eMailTo@StefanStroehlein.de) |
wer interesse an der dll hat kann mir unter >eMailTo@StefanStroehlein.de< mailen, ich schicke sie euch gerne zu. das macht auch den kreis der tester größer und ich kann bugs schneller entfernen. die aktuellste version ist 1.3
Sven Schmidts
| Datum:27.03.02 11:04 (schmidts@flat2serv.de) |
Roland, wo Du schonmal mitliest: Es wäre perfekt, wenn Du die Runtime / den Compiler, neben dem DEFINE Feature um folgendes Feature erweiterst: Es sollte direktiven geben, welche den Zeilen-Zähler ausser Kraft setzen. Beispiel: '{$COUNTOFF} Diese Zeile wird beim Zählen übersehen '{$COUNTON} Erklärung: Wenn wir im Editor zusätzliche Funktionen, auf PlugIn Basis, einbauen, dann kann der Editor bzw. das PlugIn Befehlszeilen in das Programm integrieren, wobei die Nummerierung trotzdem stimmt. Diese Zeilen dürfen bei der Nummerierung nicht beachtet werden ("Fehler in Zeile ..."). Perfekt wäre es, wenn es ausserdem noch eine Direktive á la '{$ERROROFF} gebe. Als Beispiel sei mal ein Profiler erwählt. Der Editor würde zum Beispiel folgenden Code in eine Prozedur einfügen: (Original) Proc Test A$="Test" B$="Dies ist "+A$ EndProc (Verändert durch Editor oder PlugIn) Proc Test '{$ERROROFF} {$COUNTOFF} CallExternalFunc(1) ' ext. Profiler starten '{$ERRORON} {$COUNTON} A$="Test" B$="Dies ist "+A$ '{$ERROROFF} {$COUNTOFF} CallExternalFunc(2) ' ext. Profiler beenden '{$ERRORON} {$COUNTON} EndProc So könnten Befehle eingefügt werden, ohne dass der Original-Source geändert wird. $ERROROFF schaltet Fehlermeldungen dynamisch ab, sodass ev. Fehler nicht angezeigt werden. $ERRORON schaltet auf den zuletzt bekannten Errorlevel zurück. Auf dieser Basis lässt sich auch ein Debugger einbauen, dieser würde dann via PlugIn gesteuert. Nur muss dazu ein Befehl in den Source eingebaut werden, was sich nach obigem Prinzip perfekt lösen lässt. Ich war ja damals (damals ... ;)) schon sehr weit mit dem Debugger, nur kam das Problem mit der Nummerierung dazwischen. Zum Thema Debugger: Es sollte optional einen Befehl geben (wieder dynamisch eingesetzt), der auf externe Programme wartet. Dann können wir im Editor ev. einen Variablenwert ändert (via eingefügtem Script) und Profan² macht erst dann weiter, wenn das ext. Programm wirklich damit fertig ist. Das würde unendliche Möglichkeiten auftun! Sven

Seiten: 1 2 | Zurück zur Übersicht

| Ein kostenloses WebMart Forum WebMart Homepage Tools kostenlos |