是否有任何将相对预期任务时间纳入计划的构建系统？

这是我的问题的一个小例子：

假设一个构建作业包含名为AD的4个独立任务。总而言之，D花费的时间比AC花费的时间更长。

无法包含相对任务时间的构建系统可能会安排如下任务：

---------------------------------------
CPU1: A  |    C   |
---------------------------------------
CPU2: B    | D                        |
---------------------------------------

相反，如果调度程序知道任务时间差异，则可以提出以下更短的调度：

---------------------------------------
CPU1: A  |  B    |   C   |
---------------------------------------
CPU2: D                        |
---------------------------------------

我的问题：

1. 是否有任何将相对预期任务时间纳入计划的构建系统？
2. 对于这种构建系统有哪些学术研究？
3. 这些构建系统（如果存在）从哪里获取时间信息？试探法，以前的构建过程中收集的时间？
4. 如果不存在这样的构建系统，为什么？是否有一个陷阱使他们不如乍一看看上去那么有价值？

Microsoft Visual Studio Team System（以前称为TFS）确实考虑了构建动作时间和并行构建；它从以前的构建历史中获取数据；虽然我不认为您可以开箱即用地获得所需的行为，但是您可以对其进行自定义。

一些优化性能的自定义任务的示例

https://veegens.wordpress.com/2013/03/26/tfs-2010-build-performance-report/

这是基于错误的假设，即“构建”任务是非并行的。

许多编译器使用多线程，因此单个任务A将使用所有CPU。因此，顺序无关紧要。对于受I / O约束的任务，尤其是涉及网络的任务，最好也从头开始并行执行所有任务：大多数时间都在等待答案上。

换句话说，顺序无关紧要，因为通常将各个任务并行化（例如编译）

编辑：

实际上，“ CPU 1上的任务A”的概念也存在缺陷。即使对于单线程任务，调度进程/线程的OS也会在每个上下文切换器中将其从CPU转移到CPU。我想大多数构建系统只会并行运行所有任务，而让OS进行调度。更长的任务将花费更长的时间，仅此而已。

假设您有一个不受I / O约束的长期运行的单线程任务，那么构建系统为其分配优先级/重要性将很容易，而不是尝试延迟较小的任务以减少来自OS的上下文切换。

即使您有如此奇怪的任务，这在实践中很少见，并且有一个花哨的调度构建系统，该系统可以基于以前的运行（唯一的了解方法）对启发式算法进行工作，但从中获得的收益可能会很小。但是，您需要维护很多额外的复杂性。