Then, you use iterators or Java5 style for loops (which use iterators) so I changed that.
Which made me think about those iterators again. According to oNyx (known from lwjgl forums) not all garbage is really that bad - e.g. they use small, short living event objects in lwjgl input and say that's fine with the gc... so what about iterators - are they really bad?
If they weren't creating 'evil' garbage (that makes the games hang on gc) I would really like to use them (esp. in Java 5 for each).
So any further clues on that little objects? Any suggestions for a test case?
My feeling is that object creation should be avoided where possible, especially in something called every frame. If it is not called often and is easier to write with a little object creation, then no big deal.
Hm now you mention it, the logging I removed did a native buffer allocation… maybe some of the big usage came from running the finalizers on that. Let me put the iterators back and check.
Still, a lot of work went into cleaning up object creation in .9 and we're using a substantially smaller amount of memory compared to the competition, so I'd hate to reverse any of that for slightly cleaner code.
I think it just depends on how tight a loop you are in. If you are in a loop that gets called a number of times per frame, you probably don't want any garbage there, however, once a frame, probably not a huge worry.
Well, a better logging system is planned I think, but I did not refer to jME logging. There was a logging function Bakchuda code that created native buffers. Native buffers are destroyed when they're collected and finalized and this is a relavitly expensive operation (compared to a heap buffer for example). Also much more so than collecting some iterators apperently
