做N件事儿，放到一个循环里做快，还是分开N个循环快？

[zengjd]

做N件事儿，放到一个循环里做快，还是分开N个循环快？
加入每件事儿都需要循环M遍。
for( int i=0;i<M ;i++)
{
doSomething1();
doSomething2();
doSomething3();
...
doSomethingN();
}
---------------------------------
for (int i=0;i<M;i++)
{
doSomething1();
}
for (int i=0;i<M;i++)
{
doSomething2();
}
for (int i=0;i<M;i++)
{
doSomething3();
}
...
for (int i=0;i<M;i++)
{
doSomethingN();
}

你认为这两种方式哪种执行的快？
...
很多人不假思索的认为，第一种快。
我做实验得出的结论。
两种方式平均执行速度一样快，几乎没有差别。

[lybelmont]

执行效率 要具体情况具体分析了 但是，从程序的可读性和简洁性、美观上，第一种更好。

[风吹腚腚凉]

引用 40 楼 zengjd 的回复:

引用 38 楼 stonespace 的回复: 理论上是合在一个循环里快，但其实绝大多数情况下你无法测量出二者的快慢差别，感觉都一样快， 是的，几乎一样快。

你写一个测试代码测试一下不就完事了？

[zengjd]

引用 44 楼 wjfwd2010 的回复:

引用 40 楼 zengjd 的回复:引用 38 楼 stonespace 的回复: 理论上是合在一个循环里快，但其实绝大多数情况下你无法测量出二者的快慢差别，感觉都一样快， 是的，几乎一样快。 你写一个测试代码测试一下不就完事了？

我都测试过了，几乎一样快啊！

[zengjd]

引用 43 楼 lybelmont 的回复:

执行效率 要具体情况具体分析了 但是，从程序的可读性和简洁性、美观上，第一种更好。

实际上，之所以产生第二种方式，恰恰是因为第二种方式在实际业务中，可读性更好。 我只是举了个简单的例子。

[风吹腚腚凉]

引用 45 楼 zengjd 的回复:

引用 44 楼 wjfwd2010 的回复: 引用 40 楼 zengjd 的回复:引用 38 楼 stonespace 的回复: 理论上是合在一个循环里快，但其实绝大多数情况下你无法测量出二者的快慢差别，感觉都一样快， 是的，几乎一样快。 你写一个测试代码测试一下不就完事了？ 我都测试过了，几乎一样快啊！

增加数据量，多对比几次比如循环个几百万次的

[blue_apple2006]

1帮人瞎掰个毛，快不快要看编译器怎么编译的，编译器有优化算法，优化的好，你写100个一样的循环也用一次循环来搞定，比较这个有意思吗，LZ 浪费大家时间。。。你不如问微软你的编译器怎么编译的。

[fsy351]

编译器会优化一部分，对于这两个程序具体还得看干什么事情。。。

[zengjd]

引用 49 楼 fsy351 的回复:

编译器会优化一部分，对于这两个程序具体还得看干什么事情。。。

比如什么样的事情会导致第二种速度比第一种明显的慢。

[我真的不是菜鸟]

不假思索的认为，第一种多线程更适合

[以专业开发人员为伍]

引用 楼主 zengjd 的回复:

很多人不假思索的认为，第一种快。 我做实验得出的结论。 两种方式平均执行速度一样快，几乎没有差别。

至少我的感觉，你有点心里太“脆弱”了。 我会注重第一种写法的比较清晰、舒服的语法，因此我当然还是“力挺”第一种写法，而不是纠缠在“速度快”上。 呵呵。自己动手写测试程序，固然可以破除我们的迷信，但是我们能不能看得“开”一些（而就此不再纠缠在“速度”上）也还是需要进一步学习的。

[以专业开发人员为伍]

引用 32 楼 zengjd 的回复:

我为什么要提出这个问题呢？ 原因是一个干了10几年的老兵，看了一眼第二种方式写的代码， 他固执的认为，第二种方式是随着doSomething的不断增多。 比第一种方式的执行效率是成指数级下降的。 有时候想想感觉悲哀，这就是国内IT业的现状。

如果是你所说的有人认为“是呈指数级下降”的，我能理解你的“悲哀”。 我们以前招聘过那样的“架构师”，除了写一些博客头头是道，做项目并不行。原因就是你所说的这个方面的因素。纯粹是教条主义，完全没有动脑筋去抓住其他99.999%的代码，而把剩下一点代码用来炫技。

[woshinia]

中国IT页确实是这样，就算是大学里的教授，对一些知识点也是一知半解，但还是要假装很懂然后教给学生。这样错误的信息就一直被传递。 另一点就是，没有一个整体的系统的架构，如楼主的问题，很多人都找不对切入点。计算机专业应该有这样的体系：CPU，寄存器等结构了解->计算机组成原理->操作系统->汇编->高级语言->软件工程。而现在所谓的IT人员一般就是高级语言和软件工程，他们的一些观点自然可笑。有些问题想要解决就必须要深入底层，要高层的知识根本无法解决。

[woshinia]

还有，外国一些专业书籍翻译过来，没几人能看懂，各种专业术语混搭乱用，没有统一标准。努力学英语吧，没有使用环境无法有专业级的提高，也无法跟上最新的一些知识术语。 这种环境之下，也就成为了码农，不是搞IT的不努力，而是这种学习模式实在是只能让努力钻研的人越来越糊涂。之前在脑子里的一些结论，一次次被打翻重写，技术也只能回环式的提高。

[ljsunlin]

低端码农，内功不足

[zengjd]

引用 52 楼 sp1234 的回复:

引用 楼主 zengjd 的回复:很多人不假思索的认为，第一种快。 我做实验得出的结论。 两种方式平均执行速度一样快，几乎没有差别。 至少我的感觉，你有点心里太“脆弱”了。 我会注重第一种写法的比较清晰、舒服的语法，因此我当然还是“力挺”第一种写法，而不是纠缠在“速度快”上。 呵呵。自己动手写测试程序，固然可以破除我们的迷信，但是我们能不能看得“开”一些……

你指教的对，谢谢...我会不断改正！

[挨踢直男]

时间复杂度一样， 代码质量明显第一种好了

[zengjd]

引用 52 楼 sp1234 的回复:

... 至少我的感觉，你有点心里太“脆弱”了。 ...

我有个疑问，为什么你会看出来：“至少我的感觉，你有点心里太“脆弱”了。”了呢？

[vvind]

显然这和业务逻辑强相关。 比如洗碗机，每一个碗都要经过泡水、洗洁精洗、过清水、擦干这几步，那显然第二种方法好，节约资源。 比如银行账单处理，必须用第一种方法逐个处理，把有异常的挑出来，考虑中断或回滚。 当然，单纯比较速度的话，循环体本身会有一丁丁丁点的花销，CPU切换不同的处理任务，也有一点花销，比较这两个就差不多了。 顺带，远古时代的计算机，CPU底层都是按第一种方法顺序处理的。后来发明了把相同任务集中处理的技术后，性能产生的飞跃。

[黄瓜黄瓜]

第一种看起来比较舒服的说

[cysccnu]

最根本的办法是分拆这两种算法的指令，求出所有这些指令的时钟周期数，两者的时钟周期数应该是不相等的。哪个的时钟周期数多，哪个运行的时间会长一些。 另外执行子程序需要的时钟周期应该要多一些，因为需要保存cpu的状态和下一条指令地址到堆栈，这需要花一些时间，而循环不需要。执行子程序和循环都要使计数器跳转，区别不大。 而两种算法执行子程序的数量是一样的，所以两者算法执行速度应该是差不多的。