[vlc-devel] [PATCH] Contribs: ffmpeg, enable small when deactivating encoder
funman at videolan.org
Sun Feb 5 23:59:53 CET 2012
Le 2012-02-05 17:38, Martin Storsjö a écrit :
> On Sun, 5 Feb 2012, Rafaël Carré wrote:
>> The doc says:
>> --enable-small optimize for size instead of speed
>> and it does two things:
>> * remove __attribute__((always_inline))
>> * add -Os to CFLAGS, which you override with -O2; instead of -O3 previously.
> FWIW, the "some libav guy" who suggested it to j-b was me.
> --enable-small changes a few other things within libav except for changing
> the optimization flags to -Os, it removes some extra cruft (like long
> description strings for codecs and similar minor things), and in some
> codecs chooses alternative implementations that are smaller but perhaps
> slightly slower (e.g. runtime calculation instead of using some built-in
> table or so).
> The combination of --enable-small with -O2 was based on an old benchmark
> done by me, for a different use case (building one single video encoder
> only, everything else disabled), where I tested with and without
> --enable-small, combined with optflags -Os, -O, -O2, -O3.
> In that old test, the file sizes (for libavcodec.so IIRC) were as follows:
> normal O3 1857068
> normal O2 1134524
> normal O 1087228
> normal Os 888752
> small O3 1437300
> small O2 716372
> small O 680692
> small Os 515528
> So in this case, small+O2 was the sweet spot - noticably smaller than most
> of the other configurations, not noticably slower than the other ones, and
> noticably faster than small+Os.
>> I have a few questions:
>> * Why override -O3 with -O2?
> Because -O3 IIRC more aggressively inlines stuff, which might give the
> last percent of performance, but quite massively increases the file size.
>> * Why override -Os, when you want to optimize for size?
> Because -O2 might produce faster code which isn't all that much bigger
> than with -Os.
> Also, j-b mentioned that it didn't build properly with only --enable-small
> without changing optflags to -O2, most probably due to some arm inline
> assembly that gcc wasn't able to allocate registers for when using -Os.
>> * What is the result of this patch:
>> * How much smaller is libav*?
> Don't remember exactly how much smaller it was, but the final .apk shrunk
> from 6.0 MB to 5.2 MB IIRC.
>> * How much faster/slower?
> No idea far for VLC - proper benchmarks of these different combinations is
> very much welcome I guess, in setups that are relevant for VLC (my old
> benchmarks tested just a video encoder).
>> IMO it does not make sense at all to optimize ffmpeg for size; unless
>> decoding speed is not affected negatively, or at a very small rate.
>> In any case it should be benchmarked before and after the patch.
> In my original case, it was only affected negatively at a very small rate,
> which made the trade-off sensible to me.
>> My android device is a dual core 1.2GHz with 1GB of ram, I think I have
>> enough memory to optimize FFmpeg for size.
>> Encoders are disabled because I use it to consume media, not to create.
>> I for sure have a couple megabytes of RAM to spare to get the fastest
>> decoders, especially when faster decoding means longer battery life.
>> If you are too cheap to have FFmpeg use more memory, then you should
>> have added specific options to your CFLAGS like -mthumb -Os or
>> -vomit-frame-pointer, but in the default case it should optimize for
>> speed (configure does that itself already).
> I don't think the actual installed size was the target of j-b's
> optimization, I think it was secondary to shrinking the size of the
> download package. Also, configure already adds -fomit-frame-pointer in all
> of these configurations, unless one adds --disable-optimizations.
> // Martin
Thanks for the explanation, I think we can spare a few percent on the
benchmark in exchange of smaller installed/downloaded size.
Still I would like to see some numbers before this is committed.
top seems to be fine for benchmarking
More information about the vlc-devel