[Brandon Allbery allber...@gmail.com (2011-11-25 20:50:21 UTC)]
On Fri, Nov 25, 2011 at 15:08, Harald Hanche-Olsen han...@math.ntnu.nowrote:
I have no idea what mach_kernel`chud is or does, but it disappears from
the list when the compilation is stopped. (So do the dtrace functions,
[Jeremy Lavergne jer...@lavergne.gotdns.org (2011-11-25 20:25:46 UTC)]
MacBook Pro, 2.66 GHz Intel Core 2 Duo, 8 GB RAM
Looks like build.macports.org is a quad core Xeon Xserve running 2.0, 2.66 or
3.0 GHz. If you have some ports that cannot be built in parallel, it should
give you a
I found out what has been biting me. I had been running a dtrace
script in the background to record all tcp connections in a file.
After I removed that, updating ports is so much snappier I can't
believe it.
According to the hype, dtrace is not supposed to affect system
performance, or at
On Sat, Nov 26, 2011 at 05:53, Harald Hanche-Olsen han...@math.ntnu.nowrote:
Trying that now, it didn't make any difference. Where could I found
out about options such as build.njobs, BTW? I looked around to verify
that you did RC, but to no avail.
http://guide.macports.org/#reference
On Sat, Nov 26, 2011 at 08:42, Harald Hanche-Olsen han...@math.ntnu.nowrote:
syscall::connect*:entry
syscall::connect*:return
I wonder if there's a better way to do that, in particular avoiding the
wildcards; I would suspect it ends up waking up on *every* syscall to do
the glob, which on a
[Brandon Allbery allber...@gmail.com (2011-11-26 15:46:34 UTC)]
On Sat, Nov 26, 2011 at 08:42, Harald Hanche-Olsen han...@math.ntnu.nowrote:
syscall::connect*:entry
syscall::connect*:return
I wonder if there's a better way to do that, in particular avoiding the
wildcards; I would
This thead has laid dormant for several weeks, so just a reminder:
I asked why system time was well above 50 % while I compile macports software.
[Daniel J. Luke dl...@geeklair.net (2011-10-30 15:03:08 UTC)]
If you really want to know what is going on, you could probably use some of
the
MacBook Pro, 2.66 GHz Intel Core 2 Duo, 8 GB RAM
Looks like build.macports.org is a quad core Xeon Xserve running 2.0, 2.66 or
3.0 GHz. If you have some ports that cannot be built in parallel, it should
give you a reasonable comparison.
The latest build took just under 10 minutes, where that
On Fri, Nov 25, 2011 at 15:08, Harald Hanche-Olsen han...@math.ntnu.nowrote:
I have no idea what mach_kernel`chud is or does, but it disappears from
the list when the compilation is stopped. (So do the dtrace functions,
BTW.) The script runs for ten seconds, so
CHUD is part of the
On Oct 29, 2011, at 8:54 PM, Ryan Schmidt wrote:
On Oct 29, 2011, at 09:54, Harald Hanche-Olsen wrote:
If you have another disk available without full disk encryption (an external
hard drive or thumb drive maybe), you could compile a MacPorts installation
on that drive and install some ports
Please pardon me if this is off topic, but it is about a phenomenon I
only see when macports is compiling software: So I'd like to hear if
other macports users are seeing the same:
Namely, that the majority of CPU time while compiling is system time,
not user time. Right now, for example, I am
Hi,
I noticed that too and I think this started with xcode 4.0.
Dom
Am 29.10.2011 um 16:54 schrieb Harald Hanche-Olsen han...@math.ntnu.no:
Please pardon me if this is off topic, but it is about a phenomenon I
only see when macports is compiling software: So I'd like to hear if
other
On Oct 29, 2011, at 10:54 AM, Harald Hanche-Olsen wrote:
Please pardon me if this is off topic, but it is about a phenomenon I
only see when macports is compiling software: So I'd like to hear if
other macports users are seeing the same:
Namely, that the majority of CPU time while
On Oct 29, 2011, at 09:54, Harald Hanche-Olsen wrote:
the majority of CPU time while compiling is system time,
not user time. Right now, for example, I am compiling gimp2, and top
says
CPU usage: 10.34% user, 86.20% sys, 3.44% idle
The system is a 13 inch MacBook Pro with SSD, not a HD.
14 matches
Mail list logo
