我正在尝试使用命令行工具在 Mac OS X 上分析 C/C++ 代码，我使用 -pg 选项和 gcc 在 Linux 上运行 gprof，但我似乎无法在 Mac 上找到 gprof，即使我在此页面: Additional Command-Line Tools (iOS) 或 Additional Command-Line Tools (mac) 。
gprof:Produces execution profiles based on an execution analysis of a program.
我安装了命令行工具，所以可以使用其他命令行工具，例如
otool 和 atos。我用谷歌搜索找到了这个页面( https://apple.stackexchange.com/questions/154289/installing-gprof-on-mac )，上面写着不支持 gprof，但我不确定我什么时候有描述该工具的 Apple 文档；无论如何，我尝试使用 brew 下载 gprof ，但没有用。我找到了 Attempting to use gprof with C++ code on a Mac ，但我没有
instruments -t 的输出。我也找到了 Profiling c++ on mac os x ，但我不想打开 Instruments，因为我想自动化一些流程并尝试保持跨平台系统。gprof ？ 最佳答案
很奇怪听说没有gprof OSX 分析器。 OSX是经过unix认证的，unix的分析器是gprof (基于 profil 系统调用/库函数，它在那里: https://developer.apple.com/legacy/library/documentation/Darwin/Reference/ManPages/man2/profil.2.html )。
根据 https://apple.stackexchange.com/questions/154289/installing-gprof-on-mac，GNU gprof(binutils 的一部分)存在问题(2014 年；感谢 Sreekanth Nagareddy 用户 - 已删除答案)，brew install -v binutils "*** 以下子目录不支持此配置:.. ld gas gprof"; OSX 未在 GNU gprof 自述文件中列出:http://code.metager.de/source/xref/gnu/src/gprof/README (2012) 在“支持的平台”中(仅列出 OSF/1、SunOS、Solaris、HP-UX；我认为它应该适用于 Hurd，适用于 Linux)。
但也有 gprof 的 BSD 实现(查看 https://en.wikipedia.org/wiki/gprof 以获取历史和引用资料)。没有尝试让它在 OSX 上运行(没有 OSX，也没有比 1995 年台式机和笔记本更新的苹果)。
BSD gprof 有不同的来源，例如，FreeBSD 的版本(https://github.com/freebsd/freebsd/tree/af3e10e5a78d3af8cef6088748978c6c612757f0/usr.bin/gprof)或古老的 4.3BSD 原版 http://www.retro11.de/ouxr/43bsd/usr/src/ucb/gprof/ .两种变体都不支持 OSX 中使用的 Mach-O 格式。
在 Darwin 的 cctools 中甚至还有 Apple 自己的 gprof(基于 NetBSD/OpenBSD 的 BSD gprof)(Darwin 是 UNIX 的一部分，包括 OSX 的内核和用户空间；它是/曾经/将开源):https://github.com/LeoTestard/Darwin/tree/master/cctools/gprof/https://github.com/darwin-on-arm/darwin-sdk/tree/master/cctools/gprof/http://src.gnu-darwin.org/src/usr.bin/gprof/gprof.c.html (FreeBSD 代码和 GNU 疯狂的自由思想的一些较旧的组合)。
gprof 的可用性可能取决于确切的 OSX 版本或 Xcode 版本/包；根据 http://louise.hu/poet/gprof-on-osx/，10.6.1 有 gprof或 2012 年的某个版本 - https://rachelbythebay.com/w/2012/09/14/mac/甚至在 2001 年:http://lists.apple.com/archives/darwin-development/2001/Apr/msg00617.html
有使用 instruments 的变体(Xcode 工具的一部分？)在命令行中，不知 Prop 体如何，但知道仪器是现代且功能丰富的分析器。
还有iprofiler用于收集 Instruments.app 的配置文件的命令行界面，刚刚注意到它的手册页 https://developer.apple.com/legacy/library/documentation/Darwin/Reference/ManPages/man1/iprofiler.1.html (Xcode Tools 5.0 版的一部分；来自站点遗留部分的联机帮助页)。
有第三方分析器，声明支持 OSX。我知道其中两个:valgrind 和 gperftools (google-perftools)。
valgrind 不是分析器；它是一个(缓慢的)动态检测平台，在其上构建了许多工具。它包括两个能够进行分析的工具:callgrind和 cachegrind . Valgrind 和这两个工具都不是原生分析器，它们不会分析应用程序，因为它会在现实生活中的真实 CPU 上运行。相反，valgrind 在虚拟机上执行程序，并使用计数器调用grind/cachegrind 检测机器代码。
callgrind ( http://valgrind.org/docs/manual/cl-manual.html ) 使用每个线性指令块的计数器来计算“每条指令将执行多少次”(“Ir”事件，用于获取配置文件 - 按使用时间百分比对函数进行排序)；它还记录调用/返回以构建调用图。 “Ir”事件计数对于获取指令执行计数是正确的(它也可以模拟分支预测)；但它不能用于估计实际运行时间。真正的 cpu(高性能 cpu 称为超标量；乱序 cpu 也是超标量)能够在每个 cpu 时钟周期执行多于一条指令；它也经常无法执行任何指令，因为他们可能想要一些数据被启动(来自远缓存或内存或来自系统调用或其他高延迟指令的数据；或 cpu 错误预测分支导致指令地址尚未读取/解码)。大多数渐进式 CPU 甚至可能不执行某些命令(有些每个周期最多可以执行 8 个“nop”s，几个 Intel 的 Sandy/Ivy Bridges 和更新版本不会花任何时间在“xor eax,eax”上将零写入寄存器；他们只是将下一个寄存器使用重新映射到归零的物理寄存器)。与在硬件 CPU 上的实际运行相比，callgrind 的性能分析运行速度通常会降低 10-20。
Cachegrind 实现与 callgrind 相同的检测(“Ir”，分支)，但也可以模拟缓存层次结构(缓存加载/存储/未命中事件)。而且它比 callgrind 慢。
callgrind 和 cachegrind 的输出可以用 GUI 工具 kcachegrind ( http://kcachegrind.sourceforge.net/ ，它可以在操作系统中工作) 或命令行工具 callgrind_annotate 查看.
其他工具是 gperftools(google-perftools，https://github.com/gperftools/gperftools)，它在真实的 CPU 上运行程序。要使用它，请使用自制软件安装它，然后将程序与 libprofiler 链接(添加 -Lpath_to_installed_gperftools -lprofiler )并使用 CPUPROFILE 运行环境变量设置为某个文件名( CPUPROFILE=profile01 ./the_program). It will profile the program using interval timer ( setitimer ) and output profiling data to the filename, defined in CPUPROFILE env var. Then you can view profile data in command-line or with svg/web browser using pprof perl script from gperftools ( pprof ./the_program profile01`)。
关于c++ - 如何在 Mac OS X 上从命令行进行分析？，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/29308174/