Hi, On Tue, Apr 10, 2012 at 9:27 AM, Martin Storsjö <[email protected]> wrote: > On Tue, 10 Apr 2012, Diego Biurrun wrote: > >> On Tue, Apr 10, 2012 at 07:30:30AM -0700, Ronald S. Bultje wrote: >>> >>> On Tue, Apr 10, 2012 at 7:12 AM, Diego Biurrun <[email protected]> wrote: >>>> >>>> On Fri, Mar 30, 2012 at 02:08:22AM +0200, Diego Biurrun wrote: >>>>> >>>>> --- >>>>> libavcodec/Makefile | 2 +- >>>>> libavcodec/h264.c | 358 >>>>> +++----------------------------------------------- >>>>> libavcodec/h264.h | 5 + >>>>> libavcodec/h264dec.c | 349 >>>>> ++++++++++++++++++++++++++++++++++++++++++++++++ >>>>> 4 files changed, 375 insertions(+), 339 deletions(-) >>>>> create mode 100644 libavcodec/h264dec.c >>>> >>>> >>>> ping >>> >>> >>> You told me on IRC it did not significantly decrease compile time, so >>> I don't see the point of the patch. >> >> >> That's not the only reason I went for implementing this patch. It also >> reduces the size of h264.c by 350 lines, which is not huge, but more >> than nothing, and it reduces the size of libavcodec if the H.264 decoder >> is disabled but some other part that requires h264.c is enabled. > > > Also, h264.c is one of the slowest files to compile in my experience, so I'd > see this as a step in the right direction, even it doesn't fix everything at > once.
If you want to decrease compile time, you need to un-inline one of the MC functions. I've expressed ideas in this area at some point, but someone else than me probably needs to do it. Blindly splitting code won't decrease compile time since compile time isn't uniformly distributed across the whole source file, almost all of it is in the MC code. Ronald _______________________________________________ libav-devel mailing list [email protected] https://lists.libav.org/mailman/listinfo/libav-devel
