CODEWITHSUNDEEP
c++cperformance
kal
kal

Reputation: 29401

Why is snprintf faster than ostringstream or is it?

I read somewhere that snprintf is faster than ostringstream. Has anyone has any experiences with it? If yes why is it faster.

Upvotes: 27

Views: 22462

Answers (9)

Max Lybbert
Max Lybbert

Reputation: 20039

std::ostringstream is not required to be slower, but it is generally slower when implemented. FastFormat's website has some benchmarks.

The Standard library design for streams supports much more than snprintf does. The design is meant to be extensible, and includes protected virtual methods that are called by the publicly exposed methods. This allows you to derive from one of the stream classes, with the assurance that if you overload the protected method you will get the behavior you want. I believe that a compiler could avoid the overhead of the virtual function call, but I'm not aware of any compilers that do.

Additionally, stream operations often use growable buffers internally; which implies relatively slow memory allocations.

Upvotes: 30

Matthew
Matthew

Reputation: 1

Yes, if you run the function below on a few million numbers with Visual C++ 5.0, the first version takes about twice as long as the second and produces the same output.

Compiling tight loops into a .exe and running the Windows timethis something.exe' or the Linuxtime something' is how I investigate most of my performance curiosities. (`timethis' is available on the web somewhere)

void Hex32Bit(unsigned int n, string &result)
{
#if 0
    stringstream ss;
    ss
        << hex
        << setfill('0')
        << "0x" << setw(8) << n
    ;
    result = ss.str();
#else
    const size_t len = 11;
    char temp[len];
    _snprintf(temp, len, "0x%08x", n);
    temp[len - 1] = '\0';
    result = temp;
#endif
}

Upvotes: 0

LarryF
LarryF

Reputation: 5093

It's quite possible that because sprintf is part of the CRT that is written in assembly. The ostringstream is part of the STL, and probably a little more generically written, and has OOP code/overhead to deal with.

Upvotes: 0

Luc Hermitte
Luc Hermitte

Reputation: 32966

As litb said, standard streams support many things we don't always need. Some streams implementation get rid of this never used flexibility, see FAStream for instance.

Upvotes: 0

Johannes Schaub - litb
Johannes Schaub - litb

Reputation: 507105

Some guys would possibly tell you about that the functions can't be faster than each other, but their implementation can. That's right i think i would agree.

You are unlikely to ever notice a difference in other than benchmarks. The reason that c++ streams generally tend to be slower is that they are much more flexible. Flexibility most often comes at the cost of either time or code growth.

In this case, C++ streams are based on stream-buffers. In itself, streams are just the hull that keep formatting and error flags in place, and call the right i/o facets of the c++ standard library (for example, num_put to print numbers), that print the values, well formatted, into the underlying stream-buffer connected to the c++ stream.

All this mechanisms - the facets, and the buffers, are implemented by virtual functions. While there is indeed no mark note, those functions must be implemented to be slower than c stdio pendants that fact will make them somewhat slower than using c stdio functions normally (i benchmark'ed that some time ago with gcc/libstdc++ and in fact noticed a slowdown - but which you hardly notice in day-by-day usage).

Upvotes: 8

user52875
user52875

Reputation: 3058

We replaced some stringstreams in inner loops with sprintf (using statically allocated buffers), and this made a big difference, both in msvc and gcc. I imagine that the dynamic memory management of this code:

{
  char buf[100];
  int i = 100;
  sprintf(buf, "%d", i);
  // do something with buf
}

is much simpler than

{
  std::stringstream ss;
  int i = 100;
  ss << i;
  std::string s = ss.str();
  // do something with s
}

but i am very happy with the overall performance of stringstreams.

Upvotes: 11

Johann Gerell
Johann Gerell

Reputation: 25591

One issue would probably be that the type safety added by ostringstream carries extra overhead. I've not done any measurements, though.

Upvotes: 1

sykloid
sykloid

Reputation: 101276

One reason I know that the printf family of functions are faster than the corresponding C++ functions (cout, cin, and other streams) is that the latter do typechecking. As this usually involves some requests to overloaded operators, it can take some time.

In fact, in programming competitions it is often recommended that you use printf et al rather than cout/cin for precisely this reason.

Upvotes: -1

Paul Beckingham
Paul Beckingham

Reputation: 14915

Absolutely this is implementation-specific.

But if you really want to know, write two small programs, and compare them. You would need to include typical usage for what you have in mind, the two programs would need to generate the same string, and you would use a profiler to look at the timing information.

Then you would know.

Upvotes: 3

Related Questions