【发布时间】:2012-09-12 15:31:43
【问题描述】:
作为这个问题的附录Java loop efficiency ("for" vs. "foreach")
我有一个简单的问题。增强的 for 循环是否具有更大的内存占用,或者它们会编译成相同的结构,使它们的内存占用相同,从而使for(Object o : collection) { ... } 总是更适合只读操作?
我问的原因是,在我正在使用的模拟器中,每一帧(60 帧/秒)我都在对数组中可能有数千个项目运行操作,例如要绘制的面、要针对光线跟踪等。循环
for(Object o : collection) {
o.doSomething();
}
看起来它可以制作集合的内存副本(我似乎记得在我之前的阅读中确实如此)这在大多数情况下是可以的,但如果你每秒执行 30000 次光线追踪乘以 60 次则不行。
另一方面,循环很明显
count = collection.size();
for(i = 0; i < count; i++) {
collection[i].doSomething();
}
所有内容都通过参考进行,并且占用空间相对较小,尽管它更难阅读(虽然老实说,并不多)
各位,有什么想法吗?
(注意:阅读 for 循环的难度的影响仅在您进入多层时才明显 - 对于单层 fors 增益非常小。我从经验中这么说...collection[i].property.subcollection[j].row[k].col[l].prop.subtable[m] 成为一个令人心碎的人,特别是如果其中一些需要演员:例如((Type3)((Type2)((Type1)collection[i]).property.subcollection[j].row[k]).col[l].prop).subtable[m]。)
【问题讨论】:
-
好吧,我至少可以告诉您,第二个实际上允许您更改列表而不会破坏迭代器,也就是 ConcurrentModificationException 地狱。这确实很有用。
-
你的第二个循环不会编译。
collection是数组还是Collection? -
增强 for 循环将变成基于迭代器的循环。因此,它的开销可能会稍高一些。但是,JIT 可能会摆脱这种开销。
-
@RiverC - 除非你只使用
Iterator.remove()... -
@RiverC:我只是说数组的 foreach 循环编译为与
Iterable不同的字节码。我想这与您的问题有关...
标签: java memory-management loops for-loop