[vlc-devel] [PATCH] Contribs: ffmpeg, enable small when deactivating encoder

[Rafaël Carré]

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