Code schneller machen, ..

Für Fragen zur Programmiersprache auf welcher Lazarus aufbaut
Benutzeravatar
theo
Beiträge: 10899
Registriert: Mo 11. Sep 2006, 19:01

Re: Code schneller machen, ..

Beitrag von theo »

corpsman hat geschrieben: Das einbaun der Stringlist, bringt bei mir eher eine Verschlechterung, als eine Verbesserung (zumindest wenn ich es mittels Gettickcount vermesse ).
So war es auch nicht gemeint. Wenn du nur die StringList füllst (ohne nachher an Synedit zu übergeben) siehst du einfach, wieviel für das Befüllen von Synedit "draufgeht", nämlich der zeitliche Unterschied.
Bei meinem Test dauerte das füllen der SL etwa 3 Sekunden statt 20 Sekunden für das Synedit. D.h. wenn du an deinem Code rumschraubst, verbesserst du höchstens die 3 Sekunden, nicht die 17.

carli
Beiträge: 657
Registriert: Sa 9. Jan 2010, 17:32
OS, Lazarus, FPC: Linux 2.6.x, SVN-Lazarus, FPC 2.4.0-2
CPU-Target: 64Bit

Re: Code schneller machen, ..

Beitrag von carli »

Ich wiederhole die Frage noch mal: Warum willst du bei einem Hex-Editor alle Daten im RAM halten, bzw. noch schlimmer, alle Daten ins SynEdit klatschen.

Baue dir deinen eigenen Scrollbalken und lies immer nur den Teil aus der Datei, der gerade gezeigt werden soll. Wenn die Datei mal 40 MiB statt nur 20 Mib groß ist, wirst du wissen, warum.

Benutzeravatar
theo
Beiträge: 10899
Registriert: Mo 11. Sep 2006, 19:01

Re: Code schneller machen, ..

Beitrag von theo »

Ja, Carli. Du hast ausnahmsweise recht. Nur habe ich das in der ersten Antwort schon geschrieben.
Vllt. einfach mal den Thread durchlesen, hier nochmal für dich: http://www.lazarusforum.de/viewtopic.php?p=60979#p60979

Benutzeravatar
corpsman
Lazarusforum e. V.
Beiträge: 1629
Registriert: Sa 28. Feb 2009, 08:54
OS, Lazarus, FPC: Linux Mint Mate, Lazarus GIT Head, FPC 3.0
CPU-Target: 64Bit
Wohnort: Stuttgart
Kontaktdaten:

Re: Code schneller machen, ..

Beitrag von corpsman »

@mse
Also die Shortstring Variante geht nun.

Wenn ich die Variante mit dem "ohne Stream.read" nehme, dann spare ich damit ca. 0.4 Sek = 7% ( vorrausgesetzt ich kriege das mit der Letzen Zeile noch hin ).

@Theo, @Carli :

Ihr habt beide Recht, das will ich gar nicht abstreiten. Nur ist mir das schreiben einer neuen Komponente einfach zu aufwendig. Gerade kämpfe ich auch schwer damit, wenn mein Editor "nicht" Linux Dateien öffnen soll. Bzw unter Windows, wenn er Linux Dateien öffnen soll. Synedit ist toll und lädt das Zeug einfach, aber wenn man dann mittels TSynedit.selstart und TSynedit.selend auf den Klartext umrechnen will ist das eine Katastrophe.
Wie ich auch schon schrieb, habe ich vor meinen Editor nur mit kleinen Dateien zu benutzen, es geht mir hier lediglich um den Sportlichen Ehrgeiz das Laden zu beschleundigen und dabei zu lernen wie man Effizienteren Code schreibt. Den Zugriff auf Stream.memory kannte ich so noch nicht => wieder was gelernt.

Übrigens wenn ich den Inhalt der 30MB Datei direkt mittels LoadFromStream in das Synedit laden lasse, dauert es ca. 1,7 Sekunden. D.h mein Source (bzw. den bei dem mir MSE hilft) ruiniert 4 der 5.7 Sekunden.

gruß
Corpsman
Dateianhänge
Screenshot vom Hexeditor
Screenshot vom Hexeditor
--
Just try it

mse
Beiträge: 2013
Registriert: Do 16. Okt 2008, 10:22
OS, Lazarus, FPC: Linux,Windows,FreeBSD,(MSEide+MSEgui 4.6,git master FPC 3.0.4,fixes_3_0)
CPU-Target: x86,x64,ARM

Re: Code schneller machen, ..

Beitrag von mse »

corpsman hat geschrieben:@mse
Also die Shortstring Variante geht nun.
Statt "s: String[10 + 3 * 16];" würde mir eigentlich " s: array[0..buffersize-1] of char;" noch besser gefallen.
Weiter im Text.

Code: Alles auswählen

 
        s[10 + j * 3] := ToHex[(B Shr 4) And $F];
        s[10 + j * 3 + 1] := ToHex[B And $F];
 
Hier wird ziemlich viel gerechnet um die nibbles zu extrahieren. Man könnte nun eine grössere Tabelle für alle 256 Möglichkeiten pro Byte benützen:

Code: Alles auswählen

 
const
 hextable: array[byte] of array[0..1] of char =
 (
  ('0','0'),('0','1'),('0','2'),('0','3'),('0','4'),('0','5'),('0','6'),('0','7'),
  ('0','8'),('0','9'),('0','A'),('0','B'),('0','C'),('0','D'),('0','E'),('0','F'),
 
  ('1','0'),('1','1'),('1','2'),('1','3'),('1','4'),('1','5'),('1','6'),('1','7'),
  ('1','8'),('1','9'),('1','A'),('1','B'),('1','C'),('1','D'),('1','E'),('1','F'),
...
var
  textpo: pchar;
...
    textpo:= @s[10]; //für array[0..buffersize-1] of char
    For j := 0 To 15 Do Begin
        pword(textpo)^:= word(hextable[datapo[j]]);
            //die zwei zeichen auf einen rutsch, das geht nicht mit allen prozessoren
            //da das ziel auch auf ungeraden adressen liegt
        inc(textpo,3);
      End;
      inc(datapo,16);
 
Eine ähnliche Methode liesse sich auch zur Erzeugung der Adressen verwenden. Bezüglich Aufbau der Schlaufe und der Datenadressierung sind auch noch andere Versionen denkbar, da müssten wir zuerst studieren, was der Compiler daraus macht.

carli
Beiträge: 657
Registriert: Sa 9. Jan 2010, 17:32
OS, Lazarus, FPC: Linux 2.6.x, SVN-Lazarus, FPC 2.4.0-2
CPU-Target: 64Bit

Re: Code schneller machen, ..

Beitrag von carli »

corpsman hat geschrieben:@Theo, @Carli :

Ihr habt beide Recht, das will ich gar nicht abstreiten. Nur ist mir das schreiben einer neuen Komponente einfach zu aufwendig. Gerade kämpfe ich auch schwer damit, wenn mein Editor "nicht" Linux Dateien öffnen soll. Bzw unter Windows, wenn er Linux Dateien öffnen soll. Synedit ist toll und lädt das Zeug einfach, aber wenn man dann mittels TSynedit.selstart und TSynedit.selend auf den Klartext umrechnen will ist das eine Katastrophe.
Wie ich auch schon schrieb, habe ich vor meinen Editor nur mit kleinen Dateien zu benutzen, es geht mir hier lediglich um den Sportlichen Ehrgeiz das Laden zu beschleundigen und dabei zu lernen wie man Effizienteren Code schreibt. Den Zugriff auf Stream.memory kannte ich so noch nicht => wieder was gelernt.

Übrigens wenn ich den Inhalt der 30MB Datei direkt mittels LoadFromStream in das Synedit laden lasse, dauert es ca. 1,7 Sekunden. D.h mein Source (bzw. den bei dem mir MSE hilft) ruiniert 4 der 5.7 Sekunden.

gruß
Corpsman
Mein Vorschlag war auch nicht, eine komplett neue Komponente aus dem Boden zu stampfen, sondern einfach nur ein SynEdit und eine Scrollbar in ein Form zu klatschen und bei onChange der Scrollbar den Inhalt des SynEdit neu zu füllen. Damit wärst du in einer Stunde fertig und müsstest nicht Sekunde für Sekunde an Ausführungszeit bei der Stringverarbeitung rausholen, sondern die Lösung wäre ein für alle mal schnell.

Benutzeravatar
corpsman
Lazarusforum e. V.
Beiträge: 1629
Registriert: Sa 28. Feb 2009, 08:54
OS, Lazarus, FPC: Linux Mint Mate, Lazarus GIT Head, FPC 3.0
CPU-Target: 64Bit
Wohnort: Stuttgart
Kontaktdaten:

Re: Code schneller machen, ..

Beitrag von corpsman »

@mse

Endlich hab ich kapiert was du mit dem Array wolltest *g*. ich bastle das mal Rein.
--
Just try it

Antworten