c# - 将 Task.Run() 用于 Linq - 优化或瓶颈

Question

我正在尝试优化一些较旧的项目，确保它们“一直异步”并且不会在较重的负载下崩溃。

我使用了以下代码片段的变体，不确定 Task.Run 是优化还是可能的瓶颈。这种方法在一些较大的表单中得到了相当大的使用。

public static Task<List<SelectListItem>> ToMultipleSelectListItems<T>(this List<T> items, Func<T, string> nameSelector, Func<T, Guid> valueSelector, List<Guid> selected, Func<T, string> orderBy)
{
    Task<List<SelectListItem>> selectList = Task.Run(() => items.OrderBy(orderBy).Select(item =>
                    new SelectListItem
                    {
                        Text = nameSelector(item),
                        Value = valueSelector(item).ToString(),
                        Selected = selected.Contains(valueSelector(item))
                    }).ToList());
    return selectList;
}

调用示例..

model.Abilities = await (await Api.GetAbilities()).ToMultipleSelectListItems(
    x => x.Name, 
    x => x.Id, 
    model.Task.SelectedAbilitiesList, 
    x => x.OrderBy.ToString()
);

在我看来，当前线程在返回之前仍需要等待新线程的响应。因此，在某些负载下，这可能会对 CPU 造成压力，甚至可能使线程达到最大值。我看不到好处。

如果您对此场景中的最佳实践有任何反馈，我们将不胜感激。

Answer 1

没有好处。此代码会对可扩展性产生负面影响，并且不会提供任何好处。

Someone saw an upside and wrote this in the first place,

不，对不起。

这只是一种效率较低的方法:

public static List<SelectListItem> ToMultipleSelectListItems<T>(this List<T> items, Func<T, string> nameSelector, Func<T, Guid> valueSelector, List<Guid> selected, Func<T, string> orderBy)
{
  return items.OrderBy(orderBy).Select(item =>
      new SelectListItem
      {
          Text = nameSelector(item),
          Value = valueSelector(item).ToString(),
          Selected = selected.Contains(valueSelector(item))
      }).ToList());
}

model.Abilities = (await Api.GetAbilities()).ToMultipleSelectListItems(
    x => x.Name, 
    x => x.Id, 
    model.Task.SelectedAbilitiesList, 
    x => x.OrderBy.ToString()
);

Any feedback on best practice in this scenario would be appreciated.

这里是相关的最佳实践:“避免在 ASP.NET 上使用 Task.Run”。引用我的Intro to Async ASP.NET article :

You can kick off some background work by awaiting Task.Run, but there’s no point in doing so. In fact, that will actually hurt your scalability by interfering with the ASP.NET thread pool heuristics. If you have CPU-bound work to do on ASP.NET, your best bet is to just execute it directly on the request thread. As a general rule, don’t queue work to the thread pool on ASP.NET.