在标准设置中，一个模块运行有多个线程， 我们可以使用实时时间（也就是挂钟时间）和线程时间（模块使用的所有线程所花费的总时间）为程序计时。 如果实时时间很短，那么我们就没有问题。 该程序很快完成，无需优化。 但是，如果实时性很高，我们想降低它，但是我们不知道是什么导致程序变慢：算法的效率或并行化。 现在，我们可以使用线程时间来查看使用该时间的时间。 如果线程时间很短，则需要优化并行化。 如果线程时间较长，则需要对算法进行优化。
现在，这是众所周知的，并且已经说到 What do 'real', 'user' and 'sys' mean in the output of time(1)?
我们在其他设置下运行程序。 我们有大量的数据，因此我们经常需要从磁盘保存和加载数据，因为我们无法将所有数据同时保存在内存中。 为了尽可能避免IO，我们一次通过多个模块同时传输一个数据点。 举例说明：我们有两个模块A和B，以及一些数据D。 该数据是数据点d1，d2，...的集合。 然后我们的管道定义为：
disk -> d1 -> A -> d1' -> B -> d1'' -> disk
disk -> d2 -> A -> d2' -> B -> d2'' -> disk
以此类推。
现在，要添加一个额外的层，我们发现模块B速度很慢，因此我们对其进行了并行处理，它非常有效。 ...如果不是因为我们不能再依赖实时测量这一事实。 之前，我们为每个模块都有一个计时器，该计时器在计算给定数据点之前启动，之后又暂停。 现在，我们测量A和B同时运行的实时时间。
是否存在一种方法来测量流式并行化系统的时间，从而可以推理出在哪里进行优化以及是否关注算法的效率或并行化？
答案 0 :(得分：0)
尽管管道增加了很多价值，但与管道有关的错误问题是pipeline stalls的标识和修复。出于多种原因，其中一个是各个阶段的速度不同。例如（假设），第一阶段运行速度更快，每秒生成数据，但是如果第二阶段运行缓慢且每秒不能消耗数据，那么要么队列将在阶段结点处建立，要么第一阶段将停止/停顿直到第二阶段阶段完成处理先前的数据。
根据实现方式，可以通过监视接口队列或阶段的空闲/等待时间来完成检测。补救措施是几乎总是有多个较慢类型的并发阶段。另一个解决方案是将慢速阶段实际上分为两个连续但更快的阶段。