Making the HTTPd run 20% faster with qrintf-gcc; a sprintf-optimizing compiler(blog.kazuhooku.com)

blog.kazuhooku.com

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

http://blog.kazuhooku.com/2014/10/announcing-qrintf-and-qrintf-gcc.html

2 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?

kazuho12 lat temu

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.

PythonicAlpha12 lat temu

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.

penguindev12 lat temu

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.