angström schrieb:
Was spricht denn gegen den streambuf_iterator? Der liest die chars zwar einzeln aus, aber die werden ja vom Stream gebuffert. Das Buffern zweimal zu machen, kostet da nur Performanz.
Stimmt einfach nicht. Ich habe mal einen Benchmark geschrieben:
const size_t block_size = 4096;
size_t num_blocks = heap.size() / block_size;
size_t rest = heap.size() - num_blocks * block_size;
for (unsigned i = 0; i < num_blocks; ++i)
in.read(&heap[i * block_size], block_size);
in.read(&heap[num_blocks * block_size], rest);
vs.
istreambuf_iterator<char> in_it (in.rdbuf());
copy_n(in_it, heap.size(), heap.begin());
vs.
const size_t block_size = 1000000;
size_t num_blocks = heap.size() / block_size;
size_t rest = heap.size() - num_blocks * block_size;
for (unsigned i = 0; i < num_blocks; ++i)
in.read(&heap[i * block_size], block_size);
in.read(&heap[num_blocks * block_size], rest);
Durchschnitt über 20 Durchläufe, jeweils 100000000 Bytes aus einer Datei, die zu der Zeit schon komplett im Festplattenpuffer steckte (Linux, ext4, GCC 4.6 -O3):
Read, 4kB:
User: 0.0425
Sys: 0.0515
Wall: 0.0922621
istreambuf_iterator:
User: 0.4085
Sys: 0.054
Wall: 0.462917
Megabyteweise:
User: 0.0015
Sys: 0.093
Wall: 0.0936295
Alle Angaben in Sekunden.
hustbaer gewinnt den Thread.
