在TF-slim的文档中（参考read函数），我发现有多个读取器将解析后的TF示例输入（入列）到队列中，但有一个dequeue函数每次只出列一个元素。这是否会在我创建批次时造成训练的瓶颈？使用dequeue_many是否会更好？
在之前训练我的模型时，我在TensorBoard上注意到parallelreader队列总是满的 – 这是值得关注的问题吗？还是入列操作应该比出列操作更快？一般来说，出列操作是否应该出列与入列操作的读取器数量相同的示例数？
这是我的队列可视化：
我的猜测是，在任何时候出列更多的示例可能是好的，只要有一个min_after_dequeue参数来确保队列中始终有足够的示例可以进行洗牌（事实上，洗牌是多久进行一次？）。但是一次出列多个示例的权衡是什么？
回答：
这个答案展示了如何进行性能分析，对于那个示例，每个出列操作在一个线程上花费了60微秒。如果你在出列操作上使用tf.batch，它会并行运行多个出列操作，因此平均每个出列操作可能减少到12微秒。这意味着只有当你的计算时间少于12微秒时，它才会成为瓶颈。之前我检查时，调度一个单一的GPU内核调用需要5微秒，因此任何具有超过2个GPU操作的网络在评估时会花费更长时间，而dequeue不会成为瓶颈。
