On Mon, Jun 18, 2018 at 8:19 PM Michael Niedermayer <mich...@niedermayer.cc> wrote: > > On Mon, Jun 18, 2018 at 06:52:18PM +0200, Nicolas George wrote: > > Tomas Härdin (2018-06-18): > > > Others have mentioned this already, but it bears repeating: the build > > > (make) isn't what's so slow, configure is. I went ahead and did some > > > profiling on it based on the StackOverflow thread that pops up when one > > > Web-searches "bash profiling" [1]. I went with what the second guy in > > > there says, because the first method eventually invokes the OOM killer. > > > > Before that, I suspect it would have been interesting to test a > > configure from two years ago, and bissecting if it happens to be much > > faster. > > The speed of configure declined very significantly over time, here are some > quick tests, not full bisects: > > but theres another point which i have not seen anyone make but maybe i missed > it. > If changes which decrease speed go in unhindered and without correction then > no > system, not a custom one, no meson no autotools, no cmake is guranteed to > prevent such speed decline. > Of course some of the decline will be due to added features and the added > tests > they need. >
The biggest recent slowdown is undoubtly from the change to how depdencies are resolved, but the result of the change is also a much better outcome in selected link libraries and generated pkg-config files (only those appropriate for a specified library, instead of all of them). Of course one could try to investigate to implement the same thing differently, but shell is really getting at its limit there. - Hendrik _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel