I forget the exact reasoning now, but I remember it being about 10x slower than memcpy or strncpy. I think the main reason was because of the need to parse the format string.

Even then, printf and scanf are typically faster (and not even by a little bit, by a lot) than C++ iostreams formatted output, even though iostreams gets all the formatting information at compile-time, while printf has to parse the format string.

On the other hand, if people start to use snprintf in that particular form as a safe way of string copying, compilers could pattern-match this and substitute a direct implementation.

The modern C++ way of formatting strings is with std::format, or the external fmt library. It's faster than printf (and certainly streams!) while having convenient format strings (unlike streams) and optional compile time format parsing, combined with c++ type safety.

Everyone complains about streams, yet since Turbo C++ 1.0 for MS-DOS they have served me well for the kinds of applications I delivered into production with C++.

Isn't the biggest iostream bottleneck the forced sync with cstdio? You can turn that of at program start.

With that enabled it's comically slow, but even without the stdio syncing (and even operating on stringstreams) it's still much slower. For simple one-off formatting it's hard to notice, but once you write a parser for some engineering file formats (most of which are still ASCII) and have to read a few million floats here or there it becomes a really stark difference. For parsing floats specifically there are some implementations around which are optimized more, though some of the "fast and clever" ones are less accurate.

Oh I see, I thought you were comparing it to the printf style methods but compared to methods that do not take a format string that makes sense.