On 11/21/13, 7:06 AM, Michael Shal wrote:
From: "Gregory Szorc" <[email protected]>
Unified sources have probably saved sufficient CPU cycles across all of
automation to more than offset having a non-unified build-only job. I'll
defer to the Platform Team (Ehsan?) to request that from Release
Engineering.
How many CPU cycles would we have saved across all of automation if we didn't
clobber all the time in the first place?
Indeed. We'll get there. I was somewhat disappointed an in-tree Tup
backend didn't make the cut of Q4 build system goals.
But keep in mind that tests - not builds - represent the largest
financial cost to our automation. Obviously fast builds are important
because every other job depends on them completing and they are the
common component all developers need. But if shaving costs is your goal,
we should be heavily investing in testing improvements.
[1] contains the cost breakdown. Keep in mind that "build" jobs do a lot
more than just build. Here's a broken down Linux64 m-c build job from a
few hours ago:
* 80:00 total
* 3:20 chroot population (bug 851294 tracks improving)
* 2:58 repo updating (bug 851270 tracks improving)
* 35:22 building/compiling
* 5:57 symbols
* 1:02 package tests
* 1:20 packaging
* 4:11 uploading
* 2:00 misc other packaging
* 20:44 make check
I'd say ~45 minutes (56%) wall time is actual "build." The rest is tests
or automation overhead. This already makes build faster than browser
chrome mochitests. And considering the build system is one of a few
pieces of automation that attempts to use all CPU cores, it's one of the
most efficient pieces of automation. (AFAIK JS JIT tests and xpcshell
tests are the only other pieces of automation that scale out to N cores
reasonably effectively.) Need moar concurrency.
[1]
http://oduinn.com/blog/2013/11/20/the-financial-cost-of-a-checkin-part-1/
_______________________________________________
dev-platform mailing list
[email protected]
https://lists.mozilla.org/listinfo/dev-platform
