4 ms·

No, thanks, that's a pretty bad idea. 1. There's no point in optimizing memory usage by hunting iterators. If the collection overhead is becoming visible, then

No, thanks, that's a pretty bad idea. 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".

peter_lawrey 4y ago
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.
thargor90 4y ago
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%.
- ivan_gammel 4y ago
  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.
- seer-zig 4y ago
  What was the use case for the app? Was it also HFT?

peter_lawrey 4y ago

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.

thargor90 4y ago

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%.

ivan_gammel 4y ago
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.
seer-zig 4y ago
What was the use case for the app? Was it also HFT?