On Sat, Nov 28, 2015 at 10:21 AM, Ganesh Ajjanagadde <gajja...@mit.edu> wrote: > On Sat, Nov 28, 2015 at 10:06 AM, Rostislav Pehlivanov > <atomnu...@gmail.com> wrote: >> On Sat, 2015-11-28 at 09:45 -0500, Ganesh Ajjanagadde wrote: >>> >>> Removed the av_cold, did not find a way to cleanly get rid of the >>> inline. I do suggest giving it some thought; it is needless >>> executable >>> bloat since the inline does not help perf. Pushed, thanks. >>> >> Hardly a blot as it's really only used twice in the entire code and the >> function isn't a particularly big one. > > I was concerned since the generated tables are not huge; we do not > want to bloat the binary size with redundant code, else one may be > better off with hardcoded tables. > >> Moreover even if it was a big >> function used in a few more places GCC can and will magically uninline >> it > > Did not know that. I am somewhat skeptical - aacdec, aacenc (the two > usages) are compiled separately, so the compiler may lack this > information. At link time, in principle while stitching things > together, the duplication can be removed. But this will likely happen > on LTO only builds. LTO is currently very buggy - if > auto-vectorization itself is problematic in general for FFmpeg, LTO > should not be touched by any means for release builds. > > If both usages were in the same file, I agree with you.
I read up some stuff and am fine with it now. Basically, some thought made me realize that C++ would have terrible bloat issues if stuff like this was not handled well by the toolchain - think of templates and multiple instantiations across translation units, a very common occurence that people (who know C++) don't complain about since they no it is a non issue for the final executable, though they still rightly complain about the build times. If interested, see https://stackoverflow.com/questions/2174657/when-are-header-only-libraries-acceptable, http://blog2.emptycrate.com/content/nobody-understands-c-part-5-template-code-bloat. _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
