我使用以下来源编译Python 3.6 ：
-j8在将make传递给--enable-optimizations时，编译本身会按预期运行8个线程。但是，因为我也使用class SecondTextViewTask extends Thread {
@Override
public void run() {
while (true) {
if (semaphore.availablePermits() == 0 && firstTextDigit <= 9 && secondTextDigit <= 9) {
try {
Thread.sleep(1000);
runOnUiThread(new Runnable() {
@Override
public void run() {
secondTextDigit++;
secondDigit.setText(String.valueOf(secondTextDigit));
Log.e("Test== ", "" + secondTextDigit + " " + semaphore.availablePermits());
if (secondTextDigit == 9) {
semaphore.release();
}
}
});
} catch (InterruptedException e) {
e.printStackTrace();
}
}
}
}
}
我读过不推荐跳过测试，但是测试按顺序运行，而仅在一个线程上导致编译时间非常长。
我能做些什么让测试在多个线程上执行？
答案 0 :(得分：3)
我不经常构建Python以提示我仔细观察（每次发布顶部后一两次），但是你给了我一个额外的冲动，我已经戳了一下。
我认为你指的是（目前）406个测试作为构建默认目标的一部分执行。这意味着run_profile_task的{{1}}目标。使用Makefile make变量中定义的新构建的解释器运行python -m test.regrtest --pgo。
长话短说而不是：
PROFILE_TASK你可以运行：
make -j8
只重复默认定义（截至目前）并附加make PROFILE_TASK="-m test.regrtest --pgo -j8" -j8
，方便地与make使用的相同。
由于我是一个好奇的人，我不得不尝试比较两者。在我目前启动的机器上（不是非常强劲的笔记本电脑），它将回归测试时间从~23分钟减少到~8分钟。所以，感谢借口环顾四周，这可能会派上用场。 ：）
答案 1 :(得分：1)
我相信并行运行这些测试可能不会产生想要的结果。 运行这个 tests.regrtest --pgo 来训练你打开的优化。 它们是用于这些优化训练目的的基准，因为某些优化可能对不同系统产生不同的性能影响。
我相信主要目的是了解某些结构的理想大小是多少，以便您的 cpu 缓存充分发挥其潜力。
并行运行这些测试可能会让测试相互干扰 cpu 缓存，而不会给出想要的结果。 但是，我没有进行测试，如果您要一直并行运行不同的任务，这实际上可能是有益的，但在这种情况下，也许您应该编写自己的最适合您的任务的基准测试套件？
可以在此处找到这些测试中看到的典型加速： https://bugs.python.org/issue24915