Comparing stock ffmpeg with optimized ffmpeg

Recently FreeBSD changed the multimedia/ffmpeg port to drop the
-ffast-math and -fno-finite-math-only from the CFLAGS when building an
optimized binary. The following experiment was conducted to see how much of
a difference this makes.

This is the baseline run, lasting 10817 seconds total. This is of course but
a single run, although with the computer otherwise mostly idle. One would
expect this to vary by at least several seconds over multiple runs.

This run took 10826 seconds, 0.3% more time than the baseline run. That is
not a significant difference in the runtime, in my opinion. So there doesn’t
seem to be much influence from -ffast-math and -fno-finite-math-only
in this test. It could be that this is because I’m not using a complicated
filter graph in this test, just a crop operation. The format conversion is
presumably handled by the libvpx and libvorbis libraries.

As a further test, I disabled the OPTIMIZED_CFLAGS, and re-built the program.

> dvd2webm impulse.mpg
INFO: processing 'impulse.mpg'.INFO: started at 2017-01-07 10:10:54.INFO: looking for cropping.INFO: using tile-columns flag set to 1.INFO: using 3 threads.INFO: using cropping 704:560:10:6.INFO: running pass 1...INFO: pass 1 took 0:32:27.INFO: running pass 2...INFO: running pass 2...INFO: pass 2 took 2:27:50.INFO: the size of 'impulse.webm' is 17% of the size of 'impulse.mpg'.

The run took 10817 seconds, 0.21% longer than the baseline time, weirdly
enough but shorter than the build with -ffast-math. This is probably due
to variations between runs being larger than variations between compilations.

Again this is not significantly different. This reinforces the conclusion that
for operation without large filter graphs, optimizations in ffmpeg itself
don’t really matter.