slow execution of built executables on a Mac

George Colpitts george.colpitts at gmail.com
Sun Nov 11 13:13:40 UTC 2018


I couldn't duplicate this, when system times were high they were usually
between 20-40% which seems high but not 80%. I am on Xcode 10.1, macOS
10.13.6 , a 4 core imac with 12 gb RAM and a hard drive not SSDs. I can't
go to Mojave as it is an old iMac. I did make -j5 using ghc 8.6.2.

The Mac doesn't have truss or strace. It does have dtrace which I believe
is the equivalent.

It might be good to open a ticket for this. As the description of how to
reproduce are a bit vague and the steps are manual, it would be ideal if
there were modified make file(s) to capture statistics using sample and
maybe dtrace or even time.

Cheers
George



On Sat, Nov 10, 2018 at 11:10 PM Ben Gamari <ben at well-typed.com> wrote:

> Richard Eisenberg <rae at cs.brynmawr.edu> writes:
>
> > OK. Well, I couldn't sample from Activity Monitor, because the
> > processes came and went too quickly. But the terminal command `sample`
> > takes a *name* as an argument, and so passing ghc-stage1 worked
> > nicely. Samples were taken during rts_dist_HC calls.
> >
> Hmmm, it looks to me like all of these are from GHC waiting on various
> things (e.g. _pthread_cond_wait, nanosleep, and pthread_join). It's
> quite surprising that these operations are chewing through cycles in
> kernel mode. I wonder how rapidly we are context switching. Perhaps we
> are quickly jumping between kernel and user mode? Perhaps strace (or I
> think the OS X equivalent is truss?) will shed some light?
>
> Cheers,
>
> - Ben
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20181111/d2c8eea0/attachment.html>


More information about the ghc-devs mailing list