库方法：是否异步？ [英] Library method: Async or not?
问题描述
我已经（可能是错误地）意识到，通常应该使需要一些时间的库方法异步。 是真的，如果是这样，当在库方法中没有什么可等待的时候该怎么办？
我正在使用以下方法设计自己的库：
I have gotten it through my head (perhaps incorrectly) that library methods that take some time should generally be made async. Is that true, and if so, how should that be done when there is nothing to await within the library method? I am designing my own library with the method:
public Dictionary<FunctionEnum, double> Evaluate(Func<uint,uint> algorithm, IList<double>
suggestedList)
它接受一个接受uint并返回uint的方法，并多次使用该方法。简而言之，我正在用最小二乘法评估算法的复杂度（BigO）。有关详细信息，请参见：
It takes in a method that takes a uint and returns a uint and uses that method many times over. In brief, I'm evaluating the complexity (BigO) of an algorithm by least squares. For the gory details see:
如果我的问题更适合codereview.stackexchange，请告诉我。
and if my question is better suited for codereview.stackexchange, please tell me.
Evaluate方法需要花费很多时间，因为它必须调用多次传递的算法方法。算法方法不是异步的。
The method Evaluate takes quite some time because it must call the algorithm method that is passed in many times. The algorithm method is not async.
我当然可以将调用算法的整个循环放在一个任务中，然后等待该任务，但是各种文章都认为这是一个糟糕的主意（示例： https://channel9.msdn.com/Events/TechEd/ Europe / 2013 / DEV-B318 ）
I could certainly put the entire loop where algorithm is called inside a Task and await the Task but various articles suggested this is a poor idea (Example: https://channel9.msdn.com/Events/TechEd/Europe/2013/DEV-B318)
在此特定练习中，我控制了定义算法的某些（但不是全部）代码，因此算法方法可以很好地定义为：
In this particular exercise, I have control of some (but not all) of the code that defines algorithms, so the algorithm method could well be defined as:
async Task<uint> algorithm(uint) { // perform algorithm }
我猜我的签名会变成： / p>
and I'm guessing my signature would become:
public async Task<Dictionary<FunctionEnum, double>> Evaluate(Func<uint,Task<uint>> algorithm, IList<double>
suggestedList)
在这种情况下，我当然可以进行异步评估并可以调用
In this case, I can certainly make Evaluate async and can certainly call
await algorithm((uint) trial[i]);
但总的来说，有人希望使用非异步调用我的Evaluate方法并非没有道理方法，我想给他/她一个估计，他们的算法是O（N），O（NLogN）等。
另外，（对我来说）尚不清楚我是否可以制定算法该方法真正异步，而无需在算法方法的主体中引入Task。例如，考虑
uint Fib（uint n）{返回第n个Fibonnacci元素）。
此方法可能需要很长时间（对于大n），但是又一次，如何使它成为一种异步方法？介绍类似await Task.Factory.StartNew（（）=> FibbonaciImplmentation（n）;）;
but in general, it's not unreasonable that somebody would want to call my Evaluate method with a non-async method, and I'd like to provide him/her with an estimate that their algorithm is O(N), O(NLogN), etc.
Also, it's not clear (to me) that I could make the algorithm method truly async without introducing a Task in the body of the algorithm method. Consider for example
uint Fib(uint n) { return the nth Fibonnacci element).
This method could take a long time (for large n), but again, how would one make it an async method? Introduce something like await Task.Factory.StartNew( () => FibbonaciImplmentation(n); ); ??
想法？谢谢！
推荐答案
Evaluate方法需要花费很长时间，因为它必须调用以下算法方法：通过了很多次。算法方法不是异步的。
The method Evaluate takes quite some time because it must call the algorithm method that is passed in many times. The algorithm method is not async.
Evaluate 方法通过定时执行来工作。由于异步通常表示I / O，并且由于I / O比CPU执行（要测量的实际算法）慢几个数量级，因此我认为异步重载不会有用。
The Evaluate method works by timing execution. Since "asynchronous" usually means I/O, and since I/O is orders of magnitude slower than CPU execution (the actual algorithm being measured), I do not believe an asynchronous overload would be useful.
我当然可以将调用算法的整个循环放在一个任务中，然后等待该任务，但各种文章都认为这是一个糟糕的主意
I could certainly put the entire loop where algorithm is called inside a Task and await the Task but various articles suggested this is a poor idea
自然同步的方法应该是同步的。
A naturally-synchronous method should be synchronous. It doesn't matter how long it takes to run.
如果 Evaluate 是由UI应用程序运行的，并且它想要保持其UI响应能力，可以调用求值方法包装在 Task.Run 中。
If Evaluate is run by a UI application, and it wants to keep its UI responsive, it can call the Evaluate method wrapped in a Task.Run.
这篇关于库方法：是否异步？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
