On Tue, Sep 30, 2003 at 09:33:17PM +0200, Christophe de VIENNE wrote:
> Le Mardi 30 Septembre 2003 19:58, Jonathan Wakely a écrit :
> > On Sun, Sep 28, 2003 at 11:33:55PM +0200, Christophe de Vienne wrote:
> > > I've made small tests with write_to_stream and write_to_string.
> > > It appeared that using write_to_stream is _much_ slower than
> > > write_to_string then sending the result to the stream, even if using a
> > > ostringstream instead of std::cout.
> >
> > This *might* be because write_to_string followed by one call to
> > operator<<(ostream,string) can use the length of the string and perform
> > a single write, whereas write_to_stream will perform several writes to
> > the output location (whether it's a stringstream's buffer or stdout).
>
> I was thinking of something like this.
> Do you know if there is any way to change how a ostream buffer or not the
> datas before sending them ?
The best advice for improving IOStream performance is to only use C++
I/O (don't mix it with C stdio I/O) and unsynchronise the C and C++ I/O
libs. Before doing any I/O using C++ IOStreams call:
std::ios::sync_with_stdio(false);
c.f. http://gcc.gnu.org/onlinedocs/libstdc++/27_io/howto.html#8
Also, if you're reading data from std::cin non-interactively and writing
to std::cout you might speed up the writes by untying cin and cout:
std::cin.tie(0);
Without this every time you read from std::cin std::cout.flush() will be
called. This will only affect some programs (e.g. it has no effect if
you read from an ifstream not from std::cin).
How to do more than that and change the buffering is implementation-defined.
For GCC you can make an fstream use a different sized buffer like this:
char buffer[4096];
std::ofstream f;
f.rdbuf()->pubsetbuf(buffer, sizeof(buffer));
I'm not sure if this works on std::cout because I cant remember whether
it's derived from std::ofstream in GCC 3.x
Of course none of this will make any difference when writing to an
ostringstream, as you can't change it's buffer size (it's one big,
variable-sized buffer that never writes anywhere) and it's not tied to
another stream. So maybe it's just GCC being slow :-(
jon
--
IO ERIS IO ERIS ERIS
|
