On 6/12/2013 11:36 AM, Steven Schveighoffer wrote:
If I understand correctly, the buffer is flushed, and ptr is reset to the base,
the count is reset to 0. I don't see any code in there that does any kind of
realignment.
You write 7 bytes, fflush. Now, every 4K buffered write from then on is going to
write from 7..4096+7, 4096+7..8192+7, ...
That is one block or sector. The write cache of the OS or the drive will
probably absorb this hit anyway.
Write caches are not always there.
The performance hit is extremely negligible.
Only if there is a write cache (which can be turned off, and are often turned
off for removable drives).
Not only that, but the hardware can differ from file system to file system.
You are going through the file
system driver, through the disk driver, through the disk. All of those pieces
are written to optimize writes that SPECIFIC hardware. There isn't much you can
do to make this perform poorly.
Embedded systems and custom devices often do not have sophisticated hardware or
software drivers.
You are proposing that this repeated write of the first sector be done for all
file output. You probably won't notice a speed difference if write caching is
done, but that doesn't make it a good idea.
No, this is incorrect. fflush is not called on subsequent writeln.
I didn't say it was. See my other reply. In any case, if fflush is not called on
subsequent writelns, it is still possible to have the first writeln succeed, the
subsequent writelns fail and have main() return success.
