这段代码,异步执行,为什么这么慢

货郎大叔 2018-08-16 09:00:42

private async void PART_FiltrationButton_Click(object sender, RoutedEventArgs e)
{
if (cts == null)
await DoWork((cts = new CancellationTokenSource()).Token, progress);
}
private async Task DoWork(CancellationToken token, IProgress<ProgressPartialResult> progress)
{
int j = 0;
for (int m = 0; m < 8000000; m++)
{
Task mytask = Task.Run(() =>
{
j++;
});
await mytask;
if (progress != null)
{
progress.Report(new ProgressPartialResult() { Current = m + 1, Total = 8000000 });
}
if (token.IsCancellationRequested)
{
//如果取消操作
progress.Report(new ProgressPartialResult() { Current = 0, Total = 8000000 });
}
}
}
private void Progress_ProgressChanged(object sender, ProgressPartialResult e)
{
progressBar1.Value = ((double)e.Current / e.Total) * 100;
}




在上面的代码中,采用了async await关键字使用异步执行方法,遍历数为8000000,我承认比较多,但是运算逻辑很简单啊,只是一个j++,为什么最后的效果却是慢如蜗牛,运算时间至少十几分钟吧。

请问大神,为什么出现这种情况,为什么这么慢 ?
...全文
1069 22 打赏 收藏 转发到动态 举报
写回复
用AI写文章
22 条回复
切换为时间正序
请发表友善的回复…
发表回复
drifter2002 2018-08-19
  • 打赏
  • 举报
回复
创建了大量的后台线程,这些都需要从线程池中获取资源,资源争用和消耗导致慢
Lizero52 2018-08-19
  • 打赏
  • 举报
回复
“底层设计机制”
weixin_43006803 2018-08-18
  • 打赏
  • 举报
回复
“底层设计机制”。
哈哈gogo 2018-08-18
  • 打赏
  • 举报
回复
“底层设计机制”。
xuzuning 2018-08-16
  • 打赏
  • 举报
回复
还有参照组呢?
xuzuning 2018-08-16
  • 打赏
  • 举报
回复
8000000 / 8000 * 2 / 60 ≌ 33.3 分钟
并不能说明任何问题,且实际仅耗时 10分钟,可以说效率已经是很高的了

测试时的必要条件是你知道要测试什么


  • 打赏
  • 举报
回复
比如说,人家的代码可能是这样
            for (int m = 0; m < 8000000; m++)
{
j++;
if (progress != null)
{
progress.AsyncReport(m +8000000 );
}
}

正常的顺序 for 循环不会去用什么 await。
  • 打赏
  • 举报
回复
sp都说完了。

还有就是你不要debug也能稍微快点,但是本质上还是你这个框架就有问题。
  • 打赏
  • 举报
回复
另外,你在 for 循环里边使用 await,这不仅仅是“异步”,而且你还是用流程回调来拖延了 for 循环。

异步本身可以促进并行计算。但是你的代码逻辑,根本不是并行计算思路,你用 wait 其实是目的是顺序执行。你用异步、甚至貌似多线程的语法来实际上模拟顺序算法。

这其实也就是为什么有的人“滥用线程”的那种同样的思路。
  • 打赏
  • 举报
回复
有人滥用线程,到底为什么呢?你想想看就明白了。
  • 打赏
  • 举报
回复
没听说异步执行反而比同步执行“快”的!

异步是因为有整体的效率的思想,所以才异步。不是只能看到烟囱口一般的一个小小的范畴的人能理解的。所以对于许多人来说,不要滥用线程、不要学时髦。
货郎大叔 2018-08-16
  • 打赏
  • 举报
回复
引用 4 楼 starfd 的回复:
80w个task也是要等待的,开线程、执行、等待空闲线程、分配线程、执行……

是800w个。我就想问,就这么简单的运算,耗时10分钟,属于正常现象吗?
闭包客 2018-08-16
  • 打赏
  • 举报
回复
并行编程,一般在有网络等待的场景才会提升效率,否则只有反作用。
  • 打赏
  • 举报
回复
80w个task也是要等待的,开线程、执行、等待空闲线程、分配线程、执行……
货郎大叔 2018-08-16
  • 打赏
  • 举报
回复
引用 2 楼 starfd 的回复:
80万次更新UI,你将更新UI那段去掉你看要花多少时间


修改成了下面这样了:

private async Task DoWork(CancellationToken token, IProgress<ProgressPartialResult> progress)
{
int j = 0;
for (int m = 0; m < 8000000; m++)
{
Task mytask = Task.Run(() =>
{
j++;
});
await mytask;
}
}

在代码中添加断点,结果运行3分钟了,都还是没有运行完,把8000000改成8000,则2秒钟就达到断点处了。
  • 打赏
  • 举报
回复
80万次更新UI,你将更新UI那段去掉你看要花多少时间
cheng2005 2018-08-16
  • 打赏
  • 举报
回复
线程调度也要时间啊,而且相对来说更耗时,大哥!
  • 打赏
  • 举报
回复
引用 16 楼 sr32r345 的回复:
确实,经过我的测试,不在for循环内await,就完全不一样了,速度就正常了。
但是把await放在for循环外面,又不能报告进度了。
该怎么弄,才是正确的呢


首先你的 for 循环应该在子线程运行。其次是 for 循环本身没有什么 await,而是异步触发报告进度的任务(例如使用 BeginInvoke 方式)。

你写的代码针对你这个需求来说,完全不沾边。你去纠结与之无关的 await 语句去了。
  • 打赏
  • 举报
回复
你会发现,貌似用着“异步、线程”的语句,却干着完全相反的事情。原因是不理解多线程、异步设计模式,只是标题党。

仔细想想,用相反的方式想想“底层设计机制”。
货郎大叔 2018-08-16
  • 打赏
  • 举报
回复
确实,经过我的测试,不在for循环内await,就完全不一样了,速度就正常了。
但是把await放在for循环外面,又不能报告进度了。
该怎么弄,才是正确的呢
加载更多回复(2)

110,545

社区成员

发帖
与我相关
我的任务
社区描述
.NET技术 C#
社区管理员
  • C#
  • Web++
  • by_封爱
加入社区
  • 近7日
  • 近30日
  • 至今
社区公告

让您成为最强悍的C#开发者

试试用AI创作助手写篇文章吧