Answers:
nproc给出可用的CPU内核/线程数，例如在支持双向SMT的四核CPU上为8。
您可以make使用该-j选项并行运行的作业数量取决于许多因素：
make作业使用的内存量make的作业是I / O-或CPU结合的make -j$(nproc) 是一个不错的起点，但是只要不耗尽可用内存并开始崩溃，通常可以使用更高的值。
对于真正快速的构建，如果您有足够的内存，我建议使用tmpfs，这样大多数作业将受CPU限制，并且make -j$(nproc)将尽可能快地工作。
tmpfs，是否将目录限制为始终小于物理RAM大小？
time调用中。整理结果，重复进行泡沫冲洗-最终将时间/ j值排序。
不幸的是，即使是同一构建的不同部分，在j因子值冲突的情况下也可能是最佳的，具体取决于构建的内容，方式，当时哪些系统资源是瓶颈，构建机器上正在发生的其他情况，正在发生的情况。网络（如果使用分布式构建技术），构建中涉及的许多缓存系统的状态/位置/性能等。
编译100个微小的C文件可能比编译单个巨大的C文件要快，反之亦然。构建少量高度复杂的代码可能比构建大量直接/线性代码要慢。
即使构建的上下文也很重要-使用优化为专用服务器上的构建进行优化的j因子，以针对专有，非重叠的构建进行微调，当在同一共享服务器上并行构建的开发人员使用时（可能会花费更多时间）时间（如果是序列化的话），则不能将其合并在一起），也可以将其置于具有不同硬件配置或虚拟化的服务器上。
还有构建规范的正确性方面。非常复杂的构建可能具有竞争条件，从而导致间歇性构建失败，发生率可能随着j因子的增加或减少而发生巨大变化。
我可以继续下去。问题的关键是，你必须真正评估你在建的非常情况下您要优化的第j因素。@Jeff Schaller的评论适用：进行迭代，直到找到最合适的为止。就我个人而言，我将从nproc值开始，仅当向上尝试立即显示降级时才尝试向上和向下尝试。
最好先在假定相同的环境中测量几个相同的构建，以了解测量的可变性-如果过高，可能会危及您的整个优化工作（20％的可变性会完全抵消10％的改进/ j因子搜索中的降级读数）。
最后，恕我直言，这是更好地使用（自适应）jobserver如果支持并提供的，而不是一个固定的Ĵ因素-它始终提供了跨语境的范围更宽更好的构建性能。
-j参数传递固定数字吗？例如make -j
make -j将产生依赖项所允许的尽可能多的工作，如叉子炸弹（superuser.com/questions/927836/…）；该构建将在运行过程中花费最多的CPU来爬虫，而不是运行它们（superuser.com/questions/934685/…）；在高度并行的构建中，系统将用尽内存/交换或pid＃，并且构建将失败。
最直接的方法是这样使用nproc：
make -j`nproc`
该命令nproc将返回您计算机上的内核数。通过将其包装在刻度线中，该nproc命令将首先执行，返回一个数字，该数字将传递到中make。
您可能有一些轶事经验，使用核数+ 1可以加快编译速度。这与诸如I / O延迟，其他资源延迟和资源约束的其他可用性等因素有关。
为此nproc+1，请尝试以下操作：
make -j$((`nproc`+1))
ccache以后的重建工作，但这是旧约