FYI: what it takes for RAM+swap to build devel/llvm40 with 4 processors or cores and WITH__DEBUG= (powerpc64 example)

[Brooks Davis]

On Mon, Mar 27, 2017 at 03:25:04AM -0700, Mark Millard wrote:
> On 2017-Mar-27, at 2:41 AM, Dimitry Andric <dim at FreeBSD.org> wrote:
> 
> > On 26 Mar 2017, at 23:36, Mark Millard <markmi at dsl-only.net> wrote:
> >> 
> >> I upgraded from llvm40 r4 to final. An interesting result was
> >> its creation of a backup package for llvm40-4.0.0.r4:
> >> 
> >> about 13 cpu-core-hours running pkg create
> >> 
> >> (Remember: I've been building with WITH_DEBUG= ) Its
> >> single-threaded status stands out via elapsed time
> >> approximately matching.
> >> 
> >> I'll note that it was somewhat under 6 elapsed hours for
> >> staging to have been populated (-j4 with 4 cores present
> >> helps for this part).
> >> 
> >> (Of course these elapsed-time figures are rather system
> >> dependent, although the ratio might be more stable.)
> >> 
> >> 
> >> 
> >> Also interesting was:
> >> 
> >> Installed packages to be REMOVED:
> >> 	llvm40-4.0.0.r4
> >> 
> >> Number of packages to be removed: 1
> >> 
> >> The operation will free 49 GiB.
> > 
> > Yes, this is big.  But there is no real need to build the llvm ports
> > with debug information, unless you want to hack on llvm itself.  And
> > in that case, you are better served by a Subversion checkout or Git
> > clone from upstream instead.
> > 
> > -Dimitry
> 
> FYI:
> 
> Historically unless something extreme like this ends up
> involved I build everything using WITH_DEBUG=  or explicit
> -g's in order to have better information on any failure.
> 
> This is extreme enough that next time I synchronize
> /usr/ports and it has a devel/llvm40 update I'll
> likely rebuild devel/llvm40 without using WITH_DEBUG= .
> I'm more concerned with the time it takes than with
> the file system space involved.

In the case of LLVM, enabling debug builds does a LOT more than adding
symbols.  It's much more like enabling WITNESS and INVARIANTS in your
kernel, except that the performance of the resulting binary is much
worse than a WITNESS kernel (more like 10x slowdown).

As Dimitry points out, these builds are of questionable value in ports
so garbage collecting the knob might be the sensable thing to do.

-- Brooks
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 455 bytes
Desc: not available
URL: <http://lists.freebsd.org/pipermail/freebsd-ports/attachments/20170329/b0bf746e/attachment.sig>