| Autor |
Beitrag |
wolke
 
Beiträge: 240
|
Verfasst: Sa 10.09.05 00:09
für meine kopieranwendung bin ich immer noch im unklaren darüber, welche blockgröße wohl die "beste" ist. mir ist klar, daß es so etwas wie die ideale blockgröße nicht geben kann, aber man kann ja versuchen möglichst nahe ans ziel heranzukommen. 
mein programm wird konfigurierbare blockgrößen verwenden (für lokale platten und netzwerklaufwerke unterschiedlich), außerdem habe ich mir überlegt nach dem minimieren der anwendung eine kleinere blockgröße zu verwenden und die priorität meines programms herunterzusetzen.
trotz alledem hat sich bei mir in der limiterten testumgebung (bin gerade nur mit laptop und somit einer internen festplatte "unterwegs") ergeben, daß grundsätzlich mit größerer blockgröße auch die geschwindigkeit des kopiervorgangs steigt (und zwar nicht zu knapp). natürlich mit dem nachteil, daß die balken nicht mehr oft aktualisiert werden und daß der speicherverbrauch nicht mehr akzeptabel ist. deshalb versuche ich einen kompromiss zu finden, im fertigen programm würde ich es auch von der verfügbaren speichergröße abhängig machen - problematisch bleibt noch das auslagern ins swapfile...
nichtsdestotrotz habe ich ein kleines popeliges testprogramm zusammengeschustert, das ein 300MB testfile erstellt und dieses mit unterschiedlichen blockgrößen kopiert (readfile/writefile). zum vergleich kopiert es die datei noch per file stream und mit SHFileOperation. ich würde mich freuen, wenn ein paar von euch das ding in unterschiedlichster umgebung testen (dauert ca. 10 minuten) und mir das logfile aus dem programmverzeichnis bzw. den inhalt des memos schicken oder hier posten könntet. bitte gebt noch ein paar infos zur festplatte (cache, größe) und zu eurem system (CPU, RAM virtuell/real) hinzu.
Einloggen, um Attachments anzusehen!
|
|
Luckie
Ehemaliges Mitglied
Erhaltene Danke: 1
|
Verfasst: Sa 10.09.05 01:26
  Quelltext
1:
2:
3:
4:
5:
6:
7:
8:
9:
10:
11:
12:
13:
14:
15:
16:
17:
18:
19:
20:
21:
22:
23:
| *********** 10.09.05 14:52 **********
17655371 Clusters, 1 Sectors/Cluster (16361693 frei), 512 Bytes/Sector
449615360 total, 4082219520 available.
Name: Temp, Serial: 88250CD9 Type: NTFS (3)
17655371 Clusters, 1 Sectors/Cluster (16361693 frei), 512 Bytes/Sector
449615360 total, 4082219520 available.
Name: Temp, Serial: 88250CD9 Type: NTFS (3)
Creating h:\TESTFILE.SRC (300 MB, Buffer 5 MB)...
Done. (00:14:952)
Copy to h:\TESTFILE.1 (300 MB, Buffer 1 MB) using CreateFileW/Readfile/Writefile...
Done. (00:18:727)
Kopiere nach h:\TESTFILE.5 (300 MB, Buffer 5 MB) using CreateFileW/Readfile/Writefile...
Done. (00:14:541)
Kopiere nach h:\TESTFILE.50 (300 MB, Buffer 50 MB) using CreateFileW/Readfile/Writefile...
Done. (00:14:481)
Kopiere nach h:\TESTFILE.100 (300 MB, Buffer 100 MB) using CreateFileW/Readfile/Writefile...
Done. (00:16:313)
Copy to h:\TESTFILE.STR using streams 50 MB Buffer, no progress bar)...
Done. (00:18:907)
Copy to h:\TESTFILE.SHO using SHFileOperation (Windows)...
Done. (00:11:237) |
CPU: AMD Athlon XP 1800+ (mit 1150 MHz)
OS: Windows 2000 SP4
RAM: 1 GB
Sonstiges: Virenscanner aktiv (AntiVir)
Festplatte: 5400 Umdrehungen pro Sekunde. Weitere technische Daten (Zugriffszeiten) unbekannt.
Warum hast du Streams nur mit einem 50 MB Buffer getestet? Das sagt doch nichts aus, wenn dann musst du das auch mit 1, 5, 50, 100 MB Buffern testen, um vergleichen zu können.
Und wie sieht es mit CopyFileEx aus?
|
|
retnyg
Beiträge: 2754
SNES, GB, GBA, CPC, A500, 486/66, P4/3.0HT: NintendOS, AmigaOS, DoS
Delphi 5, Delphi 7
|
Verfasst: Sa 10.09.05 01:39
wenn du den source postet kriegste von mir auch einen testbericht.
greetz
_________________ es gibt leute, die sind genetisch nicht zum programmieren geschaffen.
in der regel haben diese leute die regel...
|
|
Luckie
Ehemaliges Mitglied
Erhaltene Danke: 1
|
Verfasst: Sa 10.09.05 01:47
Feigling. 
|
|
wolke 
Beiträge: 240
|
Verfasst: Sa 10.09.05 19:34
ich sehe keinen vorteil von streams gegenüber der createfile/readfile/writefile-methode (erleuchtet mich...), und die hatte ich schon vollständig implementiert. man sieht auch im vergleich der beiden 50MB buffer, daß es sich im endeffekt nichts nimmt - mehr wollte ich gar nicht sehen, deshalb habe ich den weg nicht weiter verfolgt.
was noch fehlt ist die übernahme der attribute und evtl. der verschlüsselung, aber das kann ja nicht so viel zeit in anspruch nehmen.
copyfileex, richtig, habe ich nicht berücksichtigt, da auch diese methode für mich wegfällt - bei blockkopie kann ich die bandbreite im netzwerk sinnvoll einschränken.
interessant ist, daß bei mir SHFileOperation mit am langsamsten ist und bei dir doch schneller  schade eigentlich.
der quellcode ist mir fast zu peinlich, da es wirklich ein ziemlich "hingerotztes" testprogramm ist. nachdem mich das letzte mal schon einige von euch in die mangel genommen haben wegen unsauberer programmierung traue ich mich nicht, ihn zu posten *g*
wenn das interesse besteht würde ich evtl. den quellcode säubern, copyfileex als methode hinzufügen und variable dateigrößen und mehr blockgrößen integrieren, aber die bisherige auswahl langt eben für meine zwecke. und retnyg, wenn du nur software verwenden würdest bei denen der quellcode vorliegt wärst du gar nicht hier 
zum vergleich mein log, notebook (1.6 Centrino alte Generation, 60GB IC... platte, NOD32 virenscanner aktiv):
Quelltext
1:
2:
3:
4:
5:
6:
7:
8:
9:
10:
11:
12:
13:
14:
15:
16:
17:
18:
19:
20:
21:
22:
| 13733558 Clusters, 8 Sectors/Cluster (2325284 frei), 512 Bytes/Sector
418078720 total, 934428672 available.
Name: DATA, Serial: 410275E1 Type: NTFS (3)
13733558 Clusters, 8 Sectors/Cluster (2325284 frei), 512 Bytes/Sector
418078720 total, 934428672 available.
Name: DATA, Serial: 410275E1 Type: NTFS (3)
Creating d:\TESTFILE.SRC (300 MB, Buffer 5 MB)...
Done. (00:13:469)
Copy to d:\TESTFILE.1 (300 MB, Buffer 1 MB) using CreateFileW/Readfile/Writefile...
Done. (01:09:500)
Kopiere nach d:\TESTFILE.5 (300 MB, Buffer 5 MB) using CreateFileW/Readfile/Writefile...
Done. (01:11:687)
Kopiere nach d:\TESTFILE.50 (300 MB, Buffer 50 MB) using CreateFileW/Readfile/Writefile...
Done. (00:40:579)
Kopiere nach d:\TESTFILE.100 (300 MB, Buffer 100 MB) using CreateFileW/Readfile/Writefile...
Done. (00:35:171)
Copy to d:\TESTFILE.STR using streams 50 MB Buffer, no progress bar)...
Done. (00:41:781)
Copy to d:\TESTFILE.SHO using SHFileOperation (Windows)...
Done. (01:10:594) |
|
|
Chryzler
Beiträge: 1097
Erhaltene Danke: 2
|
Verfasst: Sa 10.09.05 20:04
Quelltext
1:
2:
3:
4:
5:
6:
7:
8:
9:
10:
11:
12:
13:
14:
15:
16:
17:
18:
19:
20:
21:
22:
| 19537040 Clusters, 8 Sectors/Cluster (5153165 frei), 512 Bytes/Sector
2714304512 total, 3927494656 available.
Name: WIN XP, Serial: D0FDFA63 Type: NTFS (3)
19537040 Clusters, 8 Sectors/Cluster (5153165 frei), 512 Bytes/Sector
2714304512 total, 3927494656 available.
Name: WIN XP, Serial: D0FDFA63 Type: NTFS (3)
Creating c:\TESTFILE.SRC (300 MB, Buffer 5 MB)...
Done. (00:23:584)
Copy to c:\TESTFILE.1 (300 MB, Buffer 1 MB) using CreateFileW/Readfile/Writefile...
Done. (00:46:797)
Kopiere nach c:\TESTFILE.5 (300 MB, Buffer 5 MB) using CreateFileW/Readfile/Writefile...
Done. (00:41:550)
Kopiere nach c:\TESTFILE.50 (300 MB, Buffer 50 MB) using CreateFileW/Readfile/Writefile...
Done. (00:48:730)
Kopiere nach c:\TESTFILE.100 (300 MB, Buffer 100 MB) using CreateFileW/Readfile/Writefile...
Done. (00:57:863)
Copy to c:\TESTFILE.STR using streams 50 MB Buffer, no progress bar)...
Done. (01:29:138)
Copy to c:\TESTFILE.SHO using SHFileOperation (Windows)...
Done. (00:54:649) |
Info:
CPU 500 MHZ
RAM 192 MB
HD 7200 Umdrehungen (glaub ich mal  )
Panda Virenscanner aktiv
|
|
alzaimar
Beiträge: 2889
Erhaltene Danke: 13
W2000, XP
D6E, BDS2006A, DevExpress
|
Verfasst: Sa 10.09.05 21:08
Dein Denkansatz ist falsch. Wenn Du Performance willst, benutze die Systempages und die WinAPI ReadFileScatter/WriteFileGather. Das könnte was bringen. Googel mal danach.
|
|
wolke
Beiträge: 240
|
Verfasst: So 11.09.05 16:34
das einzig halbwegs brauchbare dazu (abgesehen von der API dokumentation selbst) habe ich hier gefunden: nienie.com/~masapico...WriteFileGather.html
ich verstehe nicht ganz wie ich das so implementiere daß es wirklich schneller ist als readfile. im beispielcode wird WaitForSingleObject genutzt, aber geht dadurch nicht der vorteil des asynchronen lesens wieder verloren?
|
|
alzaimar
Beiträge: 2889
Erhaltene Danke: 13
W2000, XP
D6E, BDS2006A, DevExpress
|
Verfasst: So 11.09.05 17:20
Das Lustige am Scatter/Gather-IO ist, das (glaube ich) bis zu 8 (System-)Seiten ECHT parallel eingelesen werden können. Du kannst also eine gewaltige Steigerung des Durchsatzes erwarten. WaitFor ist der Preis für's asynchrone Arbeiten. Wann musst Du denn warten? Wer sagt, das das immer direkt nach dem Aufruf von Write/Read erfolgen muss? Kannst Du nicht andere Dinge in der Zwischenzeit erledigen?
Desweiteren könntest Du mit asynchronem Kopieren mittels zweier Thread experimentieren. Das klappt solange sich die Dateien nicht über die gleiche HD gehen...
|
|
|
