异步等待增加执行函数的总时间吗？

Question

与同步函数相比，我的问题涉及执行异步函数所需的总时间。

我的理解如下：

-Async函数被调用

-Code将一直执行，直到到达等待的代码为止。

执行-Whilst等待的代码(如db读取)，释放正在执行的线程以执行另一项任务。

-Once等待的代码已经完成，将分配一个线程来完成此调用。

假设我说的是正确的，那么在繁忙的服务器上异步调用可能而且通常会比同步调用慢吗？

我的理由如下：

1. 异步有一种开销(跟踪一切)。
2. 由于异步代码必须等待线程执行剩余的代码，所以必须等待线程可用-所以如果所有线程都繁忙，那么必须等待一个线程吗？

如果这是真的，那么我假设这也意味着如果有一个等待的方法没有执行任何I/O，它仍然会释放正在执行的线程并等待下一个线程可用来完成任务？

更新:我知道等待/异步不会使响应时间更快，而是让服务器更高效。

我试图澄清的主要问题是，如果异步任务已经完成，请求是否需要更长的时间才能完成?例如，如果db调用已经完成，是否需要等待更多的时间才能使线程可用？我知道有许多维度在等待，还有更多的要点需要考虑，但我只是试图孤立地理解这一点。

更新2:假设我有一个设计良好的异步系统，但是我有一个方法，我需要尽可能的快速和精益--我没有任何东西妨碍这个调用的执行时间。当然，在这种情况下，如果我使这个方法异步并释放线程，调用可能需要等待线程完成它的执行，如果它是异步的，而如果它是同步的，那么线程将一直在等待--而牺牲应用程序其余部分的性能？

Answer 1

1. 异步有一种开销(跟踪一切)。

对，是这样。然而，从异步任务中获得的速度往往远远超过开销成本，因此它可以忽略不计。除非您开始使用微小的执行主体来垃圾处理许多任务，否则开销(每个任务)将开始成为一个值得注意的因素。

我试图澄清的主要问题是，如果异步任务已经完成，请求是否需要更长的时间才能完成?例如，如果db调用已经完成，是否需要等待更多的时间才能使线程可用？

从学究上讲，这是正确的。由于等待任务完成而被搁置的“第一次”操作将无法在其任务完成的确切时间进行调整。

该操作将不得不重新加入队列，但与尚未启动的操作相比，它确实获得了优先级。这非常类似于邮局的工作方式：

• 你排队
• 到了前台，邮递员给了你一张表格(因此在等待你填写的)。
• 当邮递员可以帮助别人，而不是在她等你的时候无所事事的时候，你就站到一边填写表格。
• 当您完成您的任务时，您不会将当前被帮助的客户推开.(这似乎是你想要的:立即得到线程的关注，而不是等待它正在做的事情完成)。
• ...but你将被允许在尚未与邮递员交谈的人面前插队。

注意:至少我的文化(西欧)是这样处理这件事的。你的里程可能会不同。

所以，是的，你的假设实际上是正确的；但我想强调的是，与异步工作的收益相比，这里的时差是微不足道的。

如果您想挤压一个特定的操作以获得绝对最快的性能，则必须给它自己的线程，而不是让它参与“异步池”计划。但我强烈反对这一点，因为这样做的好处将是极其微不足道的，绝不会超过发展它的复杂性。

其次，考虑到在“设计良好的异步系统”中(根据您的问题)，任务将被划分为最小的合理操作，因此单个任务的执行(不包括之间的任何等待时间)将不会显着。在实践中，您不会注意到必须等待线程变得可用--打开您的服务器的工作量过大，并真正突破限制-在这一点上，您还有其他更大的鱼要炒。

假设我有一个设计良好的异步系统，但是我有一个方法，我需要尽可能的快速和精益--我不会为这个调用的执行时间设置任何东西。当然，在这种情况下，如果我使这个方法异步并释放线程，调用可能需要等待线程完成它的执行，如果它是异步的，而如果它是同步的，那么线程将一直在等待--而牺牲应用程序其余部分的性能？

我不明白你在这里的理由。

如果您在同步示例中假设“线程正在等待我”，这意味着该线程是可用的，并且当前不忙。但是在异步示例中，假设所有线程都很忙，没有可用的线程。

这是完全不同的情况。如果异步应用程序中的所有线程都已饱和，那么同步应用程序中的所有线程(无论是一个线程还是多个线程)都将繁忙。

异步的意图正好相反。如果一个线程当前很忙，但是在同步应用程序中空闲，您将被迫等待，并且不能使用该线程。但是，在异步应用程序中，等待线程将能够开始处理请求，因为它正在等待另一个尚未完成的任务。

Answer 2

async-await更多的是关于响应性的性能。

在客户端UI中，UI (通常)是在单个线程( UI线程)中管理的。如果阻止该线程，UI将被阻塞。async-await提供了一种机制，用于在UI线程之外启动任务，并在该任务完成后在UI线程上继续执行。该任务可以是IO任务，也可以是CPU密集型任务。主要目标是摆脱UI线程。

在服务器(ASP.NET)中，线程池是有限的，在执行IO时释放线程使应用程序能够处理更多的请求。另一方面，使用任务进行CPU密集型工作只会将一个线程池线程换两个线程。

所有这些都是额外的工作，显然，使用更多的资源(CPU周期和内存)。这都是反应能力的问题，不是性能问题。