qyot27
5th June 2012, 23:45
At first I thought this was just due to me being on the six-month release cycle for Ubuntu, with each version getting progressively heavier and making compilation take longer, or of FFmpeg getting a lot more changes integrated into it and therefore needing more time, but this last round of builds has gotten me seriously wondering if it's actually gcc itself that has the problem.
Obviously, with each new version of the OS, the version of gcc gets updated, which is why I might have blamed it on the OS requirements increasing. I'm also taking a good 3-or-so year span of time into account, and 3 years is a lot for software development and a lot of code to be added and make the time needed to compile increase accordingly.
I remember that, back in late 2008 when I started compiling these myself, that it only took a half hour to 40 minutes to compile FFmpeg (according to the package listing, I would have been using 4.3.1 at the time). It was roughly similar with the MinGW version of gcc, which I started using more than the native one in subsequent years. This gradually increased to an hour about a year ago (with MinGW gcc 4.4, as the one available in the repos sometimes tends to lag behind the native version that gets provided), and up to about 1h20m recently (with MinGW-w64 gcc 4.6.2, built using Zeranoe's build script since there were issues with the repo version and shared libraries).
Due to wanting to experiment with a newer version, I compiled 4.8.0 using the same build script (as it has the option to do that). FFmpeg took 3 hours to compile. And this is the exact same hardware and OS configuration as the 4.6.2 installation was using, and that only took 1h20m. The compile time doubled, and I can't really tell why - unless there's something special about SVN builds of gcc that use flagging meant for extra precision or debugging or something (the only alternative explanation I can think of - barring there being just a normal regression or bug in the SVN trunk causing it - is that the setup gcc is built on matters, as even though it has no problem running on this computer or producing valid binaries, it was compiled under a Virtualbox VM on a new iMac, and therefore maybe if I'd compiled it here instead I wouldn't see that ridiculous slowdown). This made me start thinking that the gradual climb might not have been due to OS upgrades or expanded software source at all, but I don't know for sure.
Is that what I'm seeing here? Any suggestions about what I could do to get the compilation times back under control (preferably not 'just use a more powerful computer')?
Obviously, with each new version of the OS, the version of gcc gets updated, which is why I might have blamed it on the OS requirements increasing. I'm also taking a good 3-or-so year span of time into account, and 3 years is a lot for software development and a lot of code to be added and make the time needed to compile increase accordingly.
I remember that, back in late 2008 when I started compiling these myself, that it only took a half hour to 40 minutes to compile FFmpeg (according to the package listing, I would have been using 4.3.1 at the time). It was roughly similar with the MinGW version of gcc, which I started using more than the native one in subsequent years. This gradually increased to an hour about a year ago (with MinGW gcc 4.4, as the one available in the repos sometimes tends to lag behind the native version that gets provided), and up to about 1h20m recently (with MinGW-w64 gcc 4.6.2, built using Zeranoe's build script since there were issues with the repo version and shared libraries).
Due to wanting to experiment with a newer version, I compiled 4.8.0 using the same build script (as it has the option to do that). FFmpeg took 3 hours to compile. And this is the exact same hardware and OS configuration as the 4.6.2 installation was using, and that only took 1h20m. The compile time doubled, and I can't really tell why - unless there's something special about SVN builds of gcc that use flagging meant for extra precision or debugging or something (the only alternative explanation I can think of - barring there being just a normal regression or bug in the SVN trunk causing it - is that the setup gcc is built on matters, as even though it has no problem running on this computer or producing valid binaries, it was compiled under a Virtualbox VM on a new iMac, and therefore maybe if I'd compiled it here instead I wouldn't see that ridiculous slowdown). This made me start thinking that the gradual climb might not have been due to OS upgrades or expanded software source at all, but I don't know for sure.
Is that what I'm seeing here? Any suggestions about what I could do to get the compilation times back under control (preferably not 'just use a more powerful computer')?