gatekeeper overhead during builds and libtool

René J.V. Bertin rjvbertin at gmail.com
Sat Feb 10 23:17:29 UTC 2024


Hi,

Does anyone else notice significant overhead from the gatekeeper daemon (or however it's called on more modern versions of the OS) during builds? This seems to be linked to intensive use of the libtool script. One of the ports where this overhead is very clearly visible is Mesa; I suspect that it will be more noticeable with project consisting of numerous tiny source files.

For a few years now I've been following a project call slibtool (https://dev.midipix.org/cross/slibtool) that aims to replace the libtool script by compiled C code, and has drop-in replacement capabilities. In some testing where I managed to get that drop-in mode to work, a complete Mesa rebuild with slibtool and primed ccache took `1072.870 user_cpu 118.142 kernel_cpu 5:59.47 total_time 331.3%CPU`. A normal build with the libtool script and the same primed ccache took `2688.511 user_cpu 1621.190 kernel_cpu 33:14.06 total_time 216.1%CPU` . Note the discrepancy between the accounted CPU time (user+kernel) and the total time; I think the differences between the 2 builds cannot be due to the different CPU loads alone but instead must be an effect of the gatekeeper daemon burning CPU.

Sadly slibtool still hasn't advanced much on Mac and in general doesn't look ready for prime-time use as a libtool replacement in random projects.

The goal of this message is to see if anyone is interested in helping that project advance but also to see if there's another way to keep that daemon in its cage that I haven't discovered (I already have configured things such that anything is allowed to run so it beats me why the daemon still burns so much CPU).

Thanks,
R.


More information about the macports-dev mailing list