Making the HTTPd run 20% faster with qrintf-gcc; a sprintf-optimizing compiler

blog.kazuhooku.com

14 points·kazuho··4 comments

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?

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.

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.

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.

Reply on news.ycombinator.com