Not logged in
Log in now
Create an account
Subscribe to LWN
LWN.net Weekly Edition for May 16, 2013
A look at the PyPy 2.0 release
PostgreSQL 9.3 beta: Federated databases and more
LWN.net Weekly Edition for May 9, 2013
(Nearly) full tickless operation in 3.10
How do you turn it off?
GCC Explorer - an interactive take on compilation
Posted May 24, 2012 17:33 UTC (Thu) by cborni (subscriber, #12949)
Posted May 24, 2012 18:10 UTC (Thu) by njs (guest, #40338)
(It's not actually that uncommon to log some strings from inside a CPU-intensive loop, and printf does have a fair amount of overhead relative to puts.)
Posted May 24, 2012 20:02 UTC (Thu) by pjm (subscriber, #2080)
The point about compilers doing these sorts of micro-optimizations is that it saves the programmer from thinking about the inefficiency and deciding whether or not there's a reasonable alternative that would avoid the inefficiency. Having a good optimizer results in more readable code, and less distracted programmers. (And as an added bonus, the code occasionally even runs faster.)
Posted May 25, 2012 6:45 UTC (Fri) by alankila (subscriber, #47141)
The sad matter of fact is that printf API is not very well designed, in that every time printf is executed, the format string is scanned again, looking for the % characters. A more carefully designed API would require you to preprocess the format string using something like printf_t format = printf_prepare("foo %d bar"), and then you could use the format repeatedly without any parsing overhead.
In this way, it would be possible to have a dumber compiler and likely more efficiency than with current printf.
Posted May 25, 2012 13:40 UTC (Fri) by vonbrand (subscriber, #4458)
Given that your compiler is allowed to assume that a function called printf is the standard printf, it can just do whatever premassaging it deems appropiate, as the example replacement by puts shows. Sure, it makes the compiler more complex and compilations take longer. The question really is if it is worth it.
Posted May 25, 2012 20:38 UTC (Fri) by mpr22 (subscriber, #60784)
Posted May 26, 2012 12:43 UTC (Sat) by alankila (subscriber, #47141)
Posted Jun 2, 2012 21:27 UTC (Sat) by vonbrand (subscriber, #4458)
Oh, come on. The compiler surely could figure out that this is printf, scan the format string and replace the whole printf("Look at this: %d %x\n", a, b) call by something along the lines of puts("Look at this: "); do_fmt_d(a); do_fmt_x(b); putchar('\n');. Probably pointless (if that is your performance bottleneck, you can do something along those lines yourself).
printf("Look at this: %d %x\n", a, b)
puts("Look at this: "); do_fmt_d(a); do_fmt_x(b); putchar('\n');
Posted Jun 3, 2012 5:37 UTC (Sun) by quotemstr (subscriber, #45331)
Posted Jun 3, 2012 9:23 UTC (Sun) by dgm (subscriber, #49227)
Posted May 28, 2012 0:00 UTC (Mon) by jamesh (guest, #1159)
In contrast, schemes like C++'s IO streams based output (which sounds a lot like what you'd expect the compiler to convert a printf call to) end up with lots of short fragments of text that are harder to translate as a unit.
Copyright © 2013, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds