循环效率
我通过 Dalvik 上的演示文稿(dalvik-vm-internals) 发现了VM，因为对于下面的循环，我们使用（2）和（3）并避免（7）。
(1) for (int i = 初始值设定项；i >= 0; i--)
(2) int limit = 计算限制； for (int i = 0; i < limit; i++)
(3) Type[] array = get array; for (Type obj : array)
(4) for (int i = 0; i < array.length; i++)
(5) for (int i = 0; i < this.var; i++)
(6) for ( int i = 0; i < obj.size();
(7) 可迭代列表 = 获取列表; for (Type obj : list)
评论：我觉得（1）和（2）是相同的。 (3) (4)每次都要计算数组的长度，这样就可以避免 (5) (6)同(4)，每次计算尺寸 (7) 要求避免，因为列表是 Iterable 类型？
还有，如果我们有无限的数据（假设数据以流的形式出现）我们应该考虑哪个循环以获得更好的效率？）
请求您对此发表评论......
I came across through a presentation(dalvik-vm-internals) on Dalvik VM, in that it is mentioned as for the below loops, we have use (2) and (3) and to avoid (7).
(1) for (int i = initializer; i >= 0; i--)
(2) int limit = calculate limit;
for (int i = 0; i < limit; i++)
(3) Type[] array = get array;
for (Type obj : array)
(4) for (int i = 0; i < array.length; i++)
(5) for (int i = 0; i < this.var; i++)
(6) for (int i = 0; i < obj.size(); i++)
(7) Iterable list = get list;
for (Type obj : list)
Comments: i feel that (1) and (2) are the same.
(3)
(4) every time it has to calculate the length of array, so this can be avoided
(5)
(6) same as (4), calculating the size everytime
(7) asked to avoid as list is of an Iterable type??
one more, in case if we have infinite data(assume data is coming as a stream) which loop should we consider for better efficiency?)
request you to please comment on this...
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
如果这是他们的建议，那么他们就为此优化了编译器和虚拟机。您认为相同的不一定以相同的方式实现：编译器可以使用各种数据和路径分析技巧来避免天真昂贵的操作。例如，由于数组是不可变的，因此可以缓存 array.length() 结果。
它们按照效率从最高到最低的顺序排列：但是（1）是“不自然的”。我同意，你同意吗？ (7) 的问题是创建了一个迭代器对象并且必须对其进行 GC。
仔细注意何时应该听取建议。它显然是用于已知集合上的有界迭代，而不是流情况。仅当循环对性能和能耗有显着影响时（“在计算机规模上运行”），它才有意义。优化的第一定律是“不要优化”。第二条定律（对于专家来说）是“暂时不要优化”。首先测量（执行时间和 CPU 消耗），然后优化：这甚至适用于移动设备。
您应该考虑的是前面的幻灯片：尝试尽可能频繁、尽可能长时间地睡觉，同时对变化做出快速反应。如何执行此操作取决于您正在处理的流类型。
最后，请注意，该演示文稿已有两年历史，可能并不完全适用于实现了 JIT 的 2.2 设备。
If that's what they recommend, that's what they've optimized the compiler and VM for. The ones you feel are the same aren't necessarily implemented the same way: the compiler can use all sorts of tricks with data and path analysis to avoid naively expensive operations. For instance, the
array.length()result can be cached since arrays are immutable.They're ranked from most to least efficient: but (1) is 'unnatural'. I agree, wouldn't you? The trouble with (7) is that an iterator object is created and has to be GC'ed.
Note carefully when the advice should be heeded. It's clearly intended for bounded iteration over a known collection, not the stream case. It's only relevant if the loop has significant effect on performance and energy consumption ('operating on the computer scale'). The first law of optimization is "Don't optimize". The second law (for experts) is "Don't optimize, yet.". Measure first (both execution times and CPU consumption), optimize later: this applies even to mobile devices.
What you should consider is the preceding slides: try to sleep as often and as long as possible, while responding quickly to changes. How you do that depends on what kind of stream you're dealing with.
Finally, note that the presentation is two years old, and may not fully apply to 2.2 devices where among other things JIT is implemented.
对于无限的数据，没有一个例子足够好。最好的办法就是做
With infinite data, none of the examples are good enough. Best would be to do
1）和2）确实不同。 2）需要额外的减法来计算 i=0 不需要。
更好的是，在大多数处理器（以及优化良好的代码）上，不需要比较 i>=0。处理器可以使用负标志，得出最后的减量(i--)。
所以循环 -1 的结尾看起来像（在伪汇编程序中）
whileloop #2
这并没有太大区别，除非循环中的代码非常小（如基本的 C 字符串操作）
这可能不适用于解释语言。
1) and 2) are really different. 2) need an extra subtraction to compute i=0 doesn't.
Even better, on most processor (and well optimized code) no is comparison needed for i>=0. The processor can use the the negative flag, resulting for the last decrement (i--).
So the end of the loop -1 looks like (in pseudo assembler)
while loop #2
That doesn't make a big difference, except if the code in your loop is really small (like basic C string operation)
That might not work with interpreted languages.