0

I'm running the compilation of a large program on Mac Os Big Sur on an M1 Mac Mini. I'm using cmake, ninja, with parallelism of 7 (there is 8 cores). It goes really really fast for the first five minutes, then really really slow. What is happening ? I don't hear any fan, and the small flow of air out of the computer does not seem warm at all. Any thing I can do ?

8
  • 1
    What does Activity monitor tell you? – X_841 Jan 26 at 20:14
  • Full cpu (80%), then low cpu(10%) – JulienFr Jan 26 at 21:33
  • 3
    Is one ninja task bigger than the others so that the build has to wait for that one? – mmmmmm Jan 26 at 21:55
  • 2
    Please edit your question and add more details. How is the RAM and energy usage? – X_841 Jan 27 at 7:06
  • 2
    How are you judging "really fast" and "really slow"? It sounds to me like the first phase (first 5 minutes) of the build has a bunch of things that can be parallelized, and the second phase (after first 5 minutes) has things that can not be built in parallel. For example, maybe the first phase is compiling a bunch of smaller files that do not directly depend on other build artifacts, and the second phase is building larger things that have a bunch of inter-dependencies. – negacao Feb 5 at 13:38
1
+50

We can dig deeper to understand what’s consuming the time, but let me preface this by saying that this may be normal behavior. I’ve seen plenty of cases where a compilation or linking phase takes a long time with large or complex projects.

Given that you’re not seeing thermal pressure and CPU utilization goes down to 10% during the slow phase, however, I’m inclined to suspect that your build is getting serialized behind a blocked process.

We can start to understand what process(es) is/are blocked by taking a stackshot during build:

  1. Run the following Terminal command to enable kernel symbolication: $ sudo nvram boot-args="keepsyms=1"
  2. Reboot your machine and don’t open any apps except for Terminal.
  3. Start your build and wait until you’ve entered the slow phase.
  4. Run the following command, making sure you’re only running it during the window of time that the build is slow: $ sudo spindump -reveal -noProcessingWhileSampling
  5. After waiting for 10 seconds to collect a sample and another minute or two to symbolicate and format, you’ll get a file in /tmp/spindump.txt that contains a stackshot of every process.
  6. Upload the file to PasteBin or some equivalent place.

That will be the most direct way to begin root-causing. Also, just to rule out memory pressure, does your system “feel” sluggish to you during the build? (I suspect not, but you should run top in another Terminal window while you’re building anyway and monitor your swapouts to see if they’re growing.)

Without knowing any of the details of the code or its build process, a crude guess would be that it’s waiting on a resource (e.g. a network server that’s slow to resolve, or an indirect filesystem lookup on a slow partition/disk). If you feel like experimenting, try disabling all of your network interfaces, unmounting every partition, and disconnecting every device.

5
  • Could not that be something like the os is Backgrounding some task ? The system could think that the user does not really care about when the large task complete, as there must be very few user interaction with the compilation, and schedule it to a low power core to free some resource for the user. – JulienFr Feb 12 at 11:42
  • 1
    Speculation isn’t useful on its own without data to help steer the investigation. I would ask that you follow the above steps so that we can understand what’s really going on. – pion Feb 12 at 11:44
  • I will provide info asap – JulienFr Feb 12 at 11:50
  • @JulienFr Any update? – pion Mar 11 at 4:38
  • I think you are right, I tried the same compilation on linux and it take the same time, with also not so intensive cpu usage. – JulienFr Mar 12 at 11:33

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .