On 15/06/2014 00:20, Mick wrote: > I looked at how long some packages are taking these days. I noticed that > firefox and chromium take a lot longer to emerge than was the case 3-4 years > ago. For example: > > # genlop -t www-client/firefox > * www-client/firefox > > Sat Dec 18 17:19:14 2010 >>> www-client/firefox-3.6.13 > merge time: 1 minute and 16 seconds. > [snip ...] > > Sat Jun 14 22:37:43 2014 >>> www-client/firefox-24.6.0 > merge time: 54 minutes and 59 seconds. > > > # genlop -t www-client/chromium > * www-client/chromium > > Sat Aug 6 09:44:27 2011 >>> www-client/chromium-13.0.782.107-r1 > merge time: 30 minutes and 52 seconds. > [snip ...] > > Sat Jun 14 21:42:44 2014 >>> www-client/chromium-35.0.1916.153 > merge time: 1 hour, 34 minutes and 49 seconds. > > > I am wondering if something in my configuration is causing this, rather than > my laptop getting older for the continuously evolving and perhaps more > demanding (in terms of resources to compile) software code. Have you noticed > something similar? >
Compilers are getting clever, I observe that to be the main reason. In years gone by, a compiler would start at the top of the .c and work towards the bottom, generating code. Hey, it works, even if the code is not the most optimum code possible. Nowadays, compilers spend ages figuring out the best code paths and optimizing. This takes time and RAM - gobs and gobs and gobs of RAM. Price of progress. A secondary factor is that packages just get bigger overall with time. Often with bloat, but not always. Your firefox example is very skewed - in the 3.x days firefox was really just a front end thingie and the bulk of the code was in backend packages (eg xulrunner). Chromium is a good example, that one has grown *enormously* And maybe your disks are tired too :-) . You do have hdparm results from 4 years ago to compare? -- Alan McKinnon [email protected]
