On Sun, Nov 12, 2017 at 11:24:11PM +0000, Gennady Kupava wrote: > In reality, gcc didn't do that and I saw 3 function calls. I am pretty > sure that compiler of the distant bright future will do that, and only > problem would be to eliminate that single function call. Hopefully > with -flto it will also eliminate this single functions call, at it > will be able to see through translation units. Given that I actually > like current implementation as it hides all details in .c file. Yeah, I agree with your analysis that we are really just overriding what could eventually be figured out by the compiler during LTO. I do think this is worth pursuing in the meantime, though, because it's not _too_ much work, and we don't know when that magical optimizing compiler will appear. :) So this frees us up in the meantime to worry less about the cost of tracing. > Now, implementation you suggesting moves extra things into .h, so it > is imperfect in terms above, while things I suggested moves only > necessary bit of checking the necessity to do anything, which is only > (interesting) part should be executed while traces are off, and the > only part we really want to be inlined. I only meant to suggest moving the necessary checking into the .h file. It's just that we have to make it a static inline for cases where we don't have variadic macros. Anyway, I'm OK with your original notion of leaving the non-variadic-macro systems on the "slow" path, so we can just go with the pure-macro thing you have. > > So it is measurable, and we might expect that tracing a really big loop > > (say over all of the objects in the repository) would benefit. OTOH, a > > real loop would actually be doing other stuff, so the speedup would be > > less dramatic. Still, it seems like an easy win. > > I actually quite familiar with performance analysis and know how to > use perf and similar tools a bit - > so if there is something more measurable in TODO, I could try. But I > guess this is interesting to many devs so such tasks probably already > all done and bottlenecks are identified in git =) There are lots of bottlenecks still to be found, I'm sure. If you want to have a go at finding some with perf, be my guest. :) -Peff
