Re:Java is very fast, if you don’t create many objects
by peter_lawrey on Thursday September 15, 2022 @12:08AM
(#32846913)
Most Iterators should be placed on the stack anyway. If they are not and you have a random access collection like ArrayList you can use an index, but this is rarely needed.
If you are going to change code, perhaps Stream(s) are a better choice, these are also placed on the stack most of the time.
Re:Java is very fast, if you don’t create many objects
by thargor90 on Monday September 12, 2022 @10:02AM
(#32810409)
Sometimes arrays are not an option, because objects may not be in memory at all times. A fun trick we use is to have the iterator be attached to the object lifecycle, so that repeated (parallel) iteration does not require multiple iterators. I can't remember the exact percentage, but this change alone increased our throughput by 20-25%.
Re:Java is very fast, if you don’t create many objects
by ivan_gammel on Monday September 12, 2022 @11:11AM
(#32811533)
That sounds both familiar and weird, like some strange lazy collection that performs an I/O operation to hydrate every time it creates iterator.
Whatever it is, it's certainly not something that would justify a modification of standard API to cover this use case.
1. There's no point in optimizing memory usage by hunting iterators. If the collection overhead is becoming visible, then you need an array, not a reset method.
2. You cannot easily add "reset()" to all iterators now, since it will be a breaking change.
3. Having reset() on all iterators 25 years ago would reduce the number of use cases for it, if this method had to be reliably supported.
3. Throwing UnsupportedOperationException in default method to maintain compatibility of libraries with existing user code would require the new client code using that method to catch the exception and handle it, which ruins the whole idea of optimization (you will get more overhead on that).
I you are concerned about performance, you have to design your code with respect to it. Building your application the same way as if performance wasn't a big problem, using the same libraries and APIs is just a bad idea that won't be salvaged by such "optimizations".