| Autor |
Beitrag |
BenBE
  
Beiträge: 8721
Erhaltene Danke: 191
Win95, Win98SE, Win2K, WinXP
D1S, D3S, D4S, D5E, D6E, D7E, D9PE, D10E, D12P, DXEP, L0.9\FPC2.0
|
Verfasst: Mo 20.10.08 17:29
Was ist an Goto eigentlich so gruselig??? Ist doch auch nur Source  _________________ Anyone who is capable of being elected president should on no account be allowed to do the job.
Ich code EdgeMonkey - In dubio pro Setting.
|
|
jaenicke
Beiträge: 19315
Erhaltene Danke: 1747
W11 x64 (Chrome, Edge)
Delphi 11 Pro, Oxygene, C# (VS 2022), JS/HTML, Java (NB), PHP, Lazarus
|
Verfasst: Mo 20.10.08 18:34
Sprich es mal aus  :
[Tiefe Stimme]Gooooo....toooooo... *echo* *schall*[/Tiefe Stimme]
|
|
Heiko 
Beiträge: 3169
Erhaltene Danke: 11
|
Verfasst: Mi 19.11.08 22:26
moin moin,
da hier ja nach Testerfahrungen gefragt wurde: also bisher habe ich nur die repne-Variante getestet. Allerdings ist die Variante um Faktor 4 langsamer als das readln von Delphi. Hat einer von euch da ne Ahnung, wo ich so ineffizient bin bzw. wie Borland es macht? Ich sehe im ASM-Code von readln leider nicht durch, wie er genau vorgeht.
Einloggen, um Attachments anzusehen!
|
|
Horst_H
Beiträge: 1654
Erhaltene Danke: 244
WIN10,PuppyLinux
FreePascal,Lazarus
|
Verfasst: Do 20.11.08 15:19
Hallo,
Dein readln bremst Dich doch garnicht:
aus deiner *.dpr habe ich statt readln einfach nur die Position geändert:
  Delphi-Quelltext
1:
2:
3:
4:
5:
6:
7:
| FSW:=TFileStreamW.Create('Test.txt', fmOpenRead);
t:=GetTickCount;
while FSW.Position<FSW.Size do
FSW.Position:= FSW.Position+i;
inc(t2, GetTickCount-t);
FSW.Free; |
Das ist 2 Sekunden schneller als readln.
readln 12,5 Sekunden /Position ändern 10,4 Sekunden.
Du suchst an der falschen Stelle nach der Bremse im System.
Gruß Horst
|
|
jaenicke
Beiträge: 19315
Erhaltene Danke: 1747
W11 x64 (Chrome, Edge)
Delphi 11 Pro, Oxygene, C# (VS 2022), JS/HTML, Java (NB), PHP, Lazarus
|
Verfasst: Do 20.11.08 15:46
Was ist i? Du änderst so doch nur die Position um einen festen Wert? Was hat das mit dem Thema zu tun?
|
|
Horst_H
Beiträge: 1654
Erhaltene Danke: 244
WIN10,PuppyLinux
FreePascal,Lazarus
|
Verfasst: Do 20.11.08 18:17
Hallo,
Es wird eine Textdatei erzeugt in der alle i Zeichen ein CR/LF/CR+LF eingefügt wird.
Damit rücke ich im Stream genauso oft vor wie das vorherige auskommentierte readln.
Also wird die while-Schleife genauso oft durchlaufen.Somit hat man ähnliche Bedingungen.
Also readln wird nicht ausgeführt, bei dem beim Einlesen auch die Position geändert wird.
Der overhead für das Einlesen und suchen nach dem Zeilenende selbst wollte ich wissen.
Das verzweifelte suchen Heiko's ,nach einer Beschleungung der CharPos - Funktion, geht also am wahren Problem vorbei.
Gruß Horst
|
|
Heiko
Beiträge: 3169
Erhaltene Danke: 11
|
Verfasst: Do 20.11.08 19:03
|
|
Horst_H
Beiträge: 1654
Erhaltene Danke: 244
WIN10,PuppyLinux
FreePascal,Lazarus
|
Verfasst: Do 20.11.08 19:44
Hallo,
| Zitat: | | Der overhead für das Einlesen und suchen nach dem Zeilenende selbst wollte ich wissen. |
Wenn man die Position in so kleinen Schritten ändert, wird der Stream vom Betreibssystem bis dorthin auch eingelesen (falls es das nicht sowieso schon ist, des vorauslesens read ahead) .
Der Zeitliche Unterschied Postion/readln rührt also nur von dem Kopieren der Streamdaten in deinen Puffer und dem suchen des Zeilenendes her.
Und da war ich erstaunt über das geringe Tempo.
Die Datei ist doch just vorher geschrieben worden und müßte noch im Cache sein und mit maximaler Geschwindigkeit gelesen werden können (ich glaube 350 oder 700 Mb/s waren da mal..) also für 1 Mb 30 ms oder so .
Und wenn man bedenkt das Delphi-readln etwas länger als Dein Overhead für Dein-readln braucht, bedeutet dies:
Delphi liest aus dem Cache und Dein readln könnte minimal schneller sein.
Lange Rede keinen Sinn:
Kannst Du meine Messwerte bestätigen Position statt readln nutzend??
Gruß Horst
|
|
Heiko
Beiträge: 3169
Erhaltene Danke: 11
|
Verfasst: Do 20.11.08 19:52
 Horst_H hat folgendes geschrieben  : | Lange Rede keinen Sinn:
Kannst Du meine Messwerte bestätigen Position statt readln nutzend?? |
Ungefähr: Borland-Radln: 3,5Sek. Mein ReadLn: 15Sek. Letzteres nur mir Pos. setzten: 10 Sek.
Allerdings verstehe ich auch nicht, wieso Borland da schneller ist. Denn eigentich müssten wir beide aufn Cache zugreifen, sofern Win den nutzt...
|
|
. Bei der Borland-readln-Variante geht er von alleine vorwärts. Bei meiner eigentlich auch.
da hätte ich das Problem echt nicht vermutet - denn der auskommentierte Test hätte da eigentlich eine auffälligkeit zeigen müssen. Tut er aber nicht. Da muss ich wohl den speedTest ml auseinanderklamüsern.