TFileStream.Write langsam, wenn man nur 1 Zeichen schreibt?

[a.def]

Ich dachte bis vor ein paar Stunden tatsächlich noch, dass das OK ist so wie ich meinen String im Speicher zusammengebaut habe.
Ich habe zwar schon von FillChar gehört wusste aber nicht, dass man es eben hier so gut einsetzen kann.

[EWeiss]

FillChar ist ein mächtiges Instrument vor allem dann wenn man Strings\Und Konsorte zurücksetzen oder die Variable in dem Fall Result initialisieren will.

Delphi-Quellcode:

FillChar(Result, SizeOf(Result), 0);

gruss

[himitsu]

FillChar ist ein "böser" Name, aber wenn man bedenkt, dass in C++ ein Byte auch als UCHAR benannt wird (unsigned char)
und dass "früher" auch im Delphi ein Char (AnsiChar) mal 1 Byte groß war.

PS: FillChar -> ZeroMemory (kennt auch Delphi)
In C++ gibt es noch SecureZeroMemory, da dort der Compiler eventuell das "Macro" ZeroMemory wegoptimiert, wenn man danach nicht mehr lesend auf diese Variable zugreift. (aber Delphi macht das nicht, also einfach den Hinweis im MSDN ignorieren :stupid:)

[EWeiss]

Wobei ich mich frage ob SetLength vor FillChar überhaupt von nöten ist denn
den Speicher könnte man direkt mit FillChar zuweisen.

Welchen Sinn macht das?

Zitat:

PS: FillChar -> ZeroMemory (kennt auch Delphi)

ZeroMemory ist doch letztendlich der WinApi32 ersatz für FillChar (Delphi).

gruss

[himitsu]

Nein, kann man nicht.
FillChar/ZeroMemory überschreibt nur bestehenden Speicher. Es wird niemals Speicher reserviert.
PS: SetLength hat schon ein FillChar integriert. (aber nur für Arrays und nicht für Strings)

In Bezug auf Strings gibt es auch noch SetString, was ein SetLength+CopyMemory ist.

Sinn, erstmal in Bezug auf CodeConvertierung zwischen Delphi und C++.
Und dann die "logische" Ausrichtung. > FillChar/MemCopy/GetMem/FreeMem, ZeroMemory/CopyMemory/GetMemory/FreeMemory usw. also wie die Frage nach Record oder Static-Class :lol:

[EWeiss]

Zitat:

FillChar/ZeroMemory überschreibt nur bestehenden Speicher. Es wird niemals Speicher reserviert.

Ok dann habe ich auch noch was dazu gelernt. ;)

Bin jetzt davon ausgegangen das dies

Delphi-Quellcode:

FillChar(aBytes, SizeOf(aBufferSize), 0);

1. Die Variable aBytes initialisiert
2. die länge von aBytes mit SizeOf zuweist
3. Den zugewiesenen Speicher mit 0 füllt.

Sollte soweit stimmen bis auf das der Speicher nicht reserviert wird.

gruss

[a.def]

Zitat:

Zitat von EWeiss (Beitrag 1358126)

Wobei ich mich frage ob SetLength vor FillChar überhaupt von nöten ist denn
den Speicher könnte man direkt mit FillChar zuweisen.

Welchen Sinn macht das?

Zitat:

PS: FillChar -> ZeroMemory (kennt auch Delphi)

ZeroMemory ist doch letztendlich der WinApi32 ersatz für FillChar (Delphi).

gruss

Ich habe SetLength jetzt dahin verlegt, wo es gebraucht wird - da, wo die Buffer-Größe verändert wird. Das passiert A) nur am Anfang vor der Schleife und B) eventuell ganz am Ende ein Mal.

[t.roller]

Zitat:

Zitat von a.def (Beitrag 1358104)

P.S.: das Tool, das mehrere GB pro Sekunde schreibt, das war auf meinem PC :P

Wie heisst das?

[Mavarik]

Zitat:

Zitat von Daniel (Beitrag 1358106)

Möglicherweise musst Du Dich noch mit dem Windows Dateicache auseinandersetzen. Ein und derselbe Code habe hier auf dem System zeigt höchst unterschiedliche Laufzeiten. Die 500 Mbytes benötigen zwischen 1.6 und 8 Sekunden, um ihren Weg auf die Platte zu finden.

Gut, auch eine Frage der Hardware...

Anbei ein Bleispiel - Dein Source ohne eine Änderung!

Einmal aus meiner Windows 10 VM

und

Einmal aus dem nativen Windows 10 wo die VM drauf läuft. (Bei laufenden VM)

8-) Mavarik

[himitsu]

FlushFileBuffers nach dem Write, dann hat man auch die Zeit bis Windows wirklich alles an den Datenträger geschickt hat.

Aus diesem Grund ist auch beim Schreiben großer Dateien der Durchsatz am Anfang größer, als zum Ende hin, nachdem der RAM überfüllt ist.
Bzw. der Explorer kopiert ja auch am Anfang schneller, außer bei Wechseldatenträgern mit deaktiviertem Schreibcache. (Stichwort "schnelles Entfernen")