| Autor |
Nachricht |
Flamefire
       
Beiträge: 1181
Erhaltene Danke: 23
Win XP
Delphi 7 Pro; Delphi 2009 Pro
|
Verfasst: Mo 21.03.11 00:11
Verwendete Sprache: Delphi
Ich habe eine Umwandlung von einem Array[n] of Char (0-Terminiert bzw bis zur max. Länge ausgefüllt) zu einem String. Danach muss das ganze noch in Kleinbuchstaben umgewandelt werden.
1. Ansatz:
Das dauert aber auch etwas. Da es sehr oft gemacht werden muss, will ich das optimieren:
So siehts bisher aus (sind 2 Versuche in einem, nehmen sich beide nix)
Damit ist das ganze ca. 10% schneller.
Hat da noch jemand Ideen für optimierungen?
|
| |
|
|
Werbung ausblenden? Dann registriere Dich kostenlos.
Weitere Gründe für eine Registrierung.
Werbung ausblenden? Dann registriere Dich kostenlos.
Weitere Gründe für eine Registrierung.
|
|
alzaimar
      
Beiträge: 2889
Erhaltene Danke: 13
W2000, XP
D6E, BDS2006A, DevExpress
|
Verfasst: Mo 21.03.11 06:18
Zeichenumwandungen würde ich über ein Array implementieren, dann spart man sich Vergleiche:
_________________ Na denn, dann. Bis dann, denn.
|
| |
|
|
Tryer
      
Beiträge: 226
Erhaltene Danke: 7
|
Verfasst: Mo 21.03.11 06:22
Einmal mit einer Vergleichstabelle (look-up table) gemacht brauchst du später nur daraus zu kopieren und auf #0 zu vergleichen.
[EDIT] zu langsam..[/EDIT]
Grüsse,
Dirk
|
| |
|
|
jaenicke
      
Beiträge: 15841
Erhaltene Danke: 741
XP, W7 x64 (Chrome, IE9, FF), Debian, (OSX 10.7)
RAD XE 2, Java (NB), C++, C# (VS 2010), JS/HTML, PHP, Lazarus
|
Verfasst: Mo 21.03.11 06:38
Am meisten Zeit kostet hier zusätzlich die if-Abfrage innerhalb der Schleife (ca. 10%). Die kann man sich auch komplett sparen. Kombiniert mit der bereits genannten Lookuptabelle, die ca. 20% bringt, sieht das dann so aus: Das SetLength am Ende kannst du dir ebenfalls sparen, denn die Zeichenanzahl kann sich ja wohl schlecht verändern.
// EDIT:
Wow, der generierte Assemblercode ist ja... suboptimal um es vorsichtig auszudrücken...
Dieser Code braucht noch ca. ein Sechstel der optimierten Variante und ein Neuntel der ursprünglichen Version... (sollte funktionieren mit Delphi 2009+) Wobei Assemblercode natürlich ein Problem bei der Umstellung auf 64-Bit ab XE 2 ist, deshalb das ifdef.
// EDIT2:
Übrigens ist bei Delphi 2006 der generierte Assemblercode noch sehr gut, der ist kaum langsamer als die selbst in Assembler geschriebene Version in XE (die ist dabei nur ca. 30% schneller, aber damit braucht die Pascal-D2006-Version von Hause aus ca. 25% der Pascal-XE-Version). Dementsprechend geändert, so läuft es jetzt erstens überall und zweitens überall schnell.
|
| |
|
|
Horst_H
       
Beiträge: 1004
Erhaltene Danke: 10
WIN7,PuppyLinux
Turbo Delphi, FreePascal
|
Verfasst: Mo 21.03.11 09:25
Hallo,
| Zitat: | | Ich habe eine Umwandlung von einem Array[n] of Char (0-Terminiert bzw bis zur max. Länge ausgefüllt) zu einem String. Danach muss das ganze noch in Kleinbuchstaben umgewandelt werden. |
Heisst das, dass die Strings wegen mir eine maximal Länge von k Zeichen haben und nur dann Nullterminiert sind, wenn sie kürzer als k sind?
Dann wären es keine echten pChar-Strings, da ist Ärger vorprogrammiert oder ist die Funktion length überladen für den Typ sIn:TSmallstring ?
Liegen die Ausgangsstrings in einem derartigem Array?
Gruß Horst
|
| |
|
|
Flamefire 
       
Beiträge: 1181
Erhaltene Danke: 23
Win XP
Delphi 7 Pro; Delphi 2009 Pro
|
Verfasst: Mo 21.03.11 11:43
Ja ist richtig. Das Array hat eine feste Länge (darum auch die Bedingung in der Schleife so, ist damit eine Konstante und so genau das gleiche wie wenn man die vorher festlegt)
Damit kann sich die Zeichenzahl ändern und ich brauche das SetLength und die überprüfung auf 0 in der Schleife.
Habe das jetzt mit der LookupTabelle gemacht, ist aber nicht wirklich schneller als ohne.
|
| |
|
|
jaenicke
      
Beiträge: 15841
Erhaltene Danke: 741
XP, W7 x64 (Chrome, IE9, FF), Debian, (OSX 10.7)
RAD XE 2, Java (NB), C++, C# (VS 2010), JS/HTML, PHP, Lazarus
|
Verfasst: Mo 21.03.11 13:20
Du solltest vielleicht das Konzept überdenken... mal mit und mal ohne Endzeichen und dann noch feste Arrays, aua... Nun gut, du kannst es einmal so testen: Ich bin gerade bei der Arbeit, deshalb kann ich gerade nicht nach der Assemblervariante schauen, aber die wäre selbst mit der Prüfung deutlich schneller.
|
| |
|
|
Horst_H
       
Beiträge: 1004
Erhaltene Danke: 10
WIN7,PuppyLinux
Turbo Delphi, FreePascal
|
Verfasst: Mo 21.03.11 14:13
Hallo,
anbei mal ein Versuch mit 10 Millionen Strings der Länge 50
Ich habe keinen Ahnung, wie hoch die Ausgangsgeschwindigkeit war.
500 Mb werden zu 1 Gb umgewandelt in 2,3 Sekunden. bei 2,9 Ghz sind das 667 Takte pro String , wer weiss wie lange setlength braucht?
Gruß Horst
EDIT:
Setlenght auf 2*MAXLAENGE dauerte 1,078 Sekunden ...also 1,078*2,9e9/ 10e6 ~ 313 Takte, also fast die Hälfte der Zeit.
Man sollte mal random Strings nehmen 26 mal umwandeln gefolgt von 24 mal nicht umwandeln verbessert die Sprungvorhersage.
So sind es 7 Takte pro Zeichen.
Zuletzt bearbeitet von Horst_H am Mo 21.03.11 14:24, insgesamt 1-mal bearbeitet
|
| |
|
|
Flamefire 
       
Beiträge: 1181
Erhaltene Danke: 23
Win XP
Delphi 7 Pro; Delphi 2009 Pro
|
Verfasst: Mo 21.03.11 14:21
@jaenicke: kann nix dafür. Ich lese aus einem Archiv, und dessen Format ist fest...
|
| |
|
|
jaenicke
      
Beiträge: 15841
Erhaltene Danke: 741
XP, W7 x64 (Chrome, IE9, FF), Debian, (OSX 10.7)
RAD XE 2, Java (NB), C++, C# (VS 2010), JS/HTML, PHP, Lazarus
|
Verfasst: Mo 21.03.11 15:08
Schlag den Urheber des Formats.  Ok, versuchs einmal so, nur schnell im Editor hier geschrieben und ungetestet: Sonst warte bis heute Abend, dann schreibe ich das noch einmal richtig hin...
|
| |
|
|
Horst_H
       
Beiträge: 1004
Erhaltene Danke: 10
WIN7,PuppyLinux
Turbo Delphi, FreePascal
|
Verfasst: Di 22.03.11 00:36
Hallo,
eine andere Variante von SmallString2String.
Delphi7 "versteht" kein UniCode. Widestring dauert ewig 26 Sekunden.
Aber testweise in Freepascal ist es doch mit 2,3 Sekunden schnell genug, oder nicht?
Etwas ist aegerlich
fpc_char_to_uchar braucht kleine Ewigkeiten.
pOut[le] := WideChar(Ord(p0[le]) OR $00)
wird zu
Gruß Horst
|
| |
|
|
Horst_H
       
Beiträge: 1004
Erhaltene Danke: 10
WIN7,PuppyLinux
Turbo Delphi, FreePascal
|
Verfasst: Di 22.03.11 09:06
Hallo,
durch die Umstellung auf die Tabelle fiel ja einiges weg und fillchar wird nicht mehr benötigt.
Das spart aber nur 6% . 2,17 war das schnellste statt 2,3 Sekunden.
Gruß Horst
EDIT:
Jetzt weiß ich, warum Delhi7 bei der Verwendung von widestrings so lange braucht.
Bei der Zuweisung wandert Delphi durch RTL-critical section und sonstwo noch lang. ( callWStrAsg ...)
Es dauert dann die besagten 26 bzw jetzt 20 Sekunden.
Der Aufruf ohne Zuweisung
dauert nur 3 Sekunden.
|
| |
|
|
jaenicke
      
Beiträge: 15841
Erhaltene Danke: 741
XP, W7 x64 (Chrome, IE9, FF), Debian, (OSX 10.7)
RAD XE 2, Java (NB), C++, C# (VS 2010), JS/HTML, PHP, Lazarus
|
Verfasst: Di 22.03.11 09:33
Es geht ja wohl ohnehin nicht um Delphi 7, sondern um Delphi 2009.
Der Grund ist, dass WideStrings von Windows via COM verwaltet werden. Das ist natürlich langsamer als eine native Lösung wie ab Delphi 2009.
|
| |
|
|
Horst_H
       
Beiträge: 1004
Erhaltene Danke: 10
WIN7,PuppyLinux
Turbo Delphi, FreePascal
|
Verfasst: Di 22.03.11 12:52
Hallo,
da muss Flamefire wissen, was er will.
Mit Freepascal ist diese Version bei mir am schnellsten.Auch damit ist UniCode schneller als widestring.
Jaenicke's Version ist minimal schneller mit strlen, aber wenn sehr viele Eingangsstrings die Länge voll ausschöpfen sucht er ja ewig die erste #0, das erscheint mir nicht koscher
Gruß Horst
|
| |
|
|
Flamefire 
       
Beiträge: 1181
Erhaltene Danke: 23
Win XP
Delphi 7 Pro; Delphi 2009 Pro
|
Verfasst: Di 22.03.11 13:16
Da es unwahrscheinlich ist, dass die Namen die volle Länge nutzen ist die Variante von jaenicke die schnellste. Ok danke.
Einziger Punkt noch: Was ist wenn er doch mal die volle Länge nutzt und dahinter erst viel später eine 0 kommt? Kann es da zu Problemen kommen?
|
| |
|
|
jaenicke
      
Beiträge: 15841
Erhaltene Danke: 741
XP, W7 x64 (Chrome, IE9, FF), Debian, (OSX 10.7)
RAD XE 2, Java (NB), C++, C# (VS 2010), JS/HTML, PHP, Lazarus
|
Verfasst: Di 22.03.11 14:43
Das ist eigentlich nur ein weiterer Vergleich, ich bin gestern Abend nur nicht dazu gekommen. Ich wollte das noch komplett als Assembler umsetzen, dann geht es ohnehin am schnellsten.
Die Variante mit StrLen sollte immer gehen, ist aber auch wohl langsamer. Hier bietet sich stattdessen repne scasb in Assembler an.
|
| |
|
|
|