
Making the HTTPd run 20% faster with qrintf-gcc; a sprintf-optimizing compiler - kazuho
http://blog.kazuhooku.com/2014/10/announcing-qrintf-and-qrintf-gcc.html
======
PythonicAlpha
Very interesting, that printf has that big impact on execution of standard
programs. Printf is very powerful (and one of the reasons for the success of C
-- for example when you compare it with the standard library existing in
Modula 2 or (old) standard Pascal), but that power also comes with a cost.

It would be interesting, how the situation is in C++ with its newer stream
based output, that is more based on compiler support (as much I know). Does
anybody have experiences with it?

~~~
kazuho
That's a very good question.

My understanding is that the main motivation behind the introduction of
iostream was to make a type-safe variant of printf. So with iostreams the
_type_ of the value is determined at compile-time, but the representation
(e.g. should it be stringified as dec or hex? should it be left-align or
right?) needs to be determined at run-time.

In other words, the design issue is only partially solved with iostreams in
terms of performance.

~~~
PythonicAlpha
Thanks for the answer. Yes, I was aware, that the focus of iostreams was not
on performance. But at least I would have some hope, that since less runtime-
parsing would be needed (at least in standard cases), a performance benefit
could arise. One of the disadvantages of printf is that even in simple cases
(e.g. "%s: %d") rather much parsing is needed.

------
penguindev
1\. nothing generic is as fast as making your own custom solution

2\. a lot of libc is lowest common denominator / tons of bloat. printf/sprintf
probably does extra locale, multibyte charset, and thread locking shit you
don't want.

