IntTree iteration produces plenty of garbage

[CodingFabian]

I am currently investigating a garbage issue created by an application using pcollections a lot. What I observed is that Iteration over an IntTree allocates plenty of Integers, as seen in below screenshot from a profiler

I see there is a comment attached to the use of "int" here: private int key = 0; // note we use int here since this is a truly absolute key

This should be fine, the autoBoxing, which creates the objects will hit the IntegerCache for "0", but I that we quickly leave the area of IntegerCache and create new Integer Instances.

Would it be possible to avoid this somehow?

[hrldcpr]

Thanks for the report, @CodingFabian!

I'm pretty sure I can change that code to avoid autoboxing entirely.

But an Entry object will still be created on every call to next(), so won't there be a lot of garbage no matter what? Or are the Integer objects worse for some reason? Does that profiling show anything about java.util.Map.Entry objects so we can compare?

Thanks!

[CodingFabian]

no objects are really bad, but I assumed that it would be possible to avoid the object here. I would see more challenge in avoiding the Entry objects, that why I have not suggested it :)

[hrldcpr]

This could be helped by making IntTree<V> extend Entry<Integer, V> so that it never has to call new SimpleImmutableEntry<Integer, V> during iteration, it can just return itself.

This is the way that the recently-added KVTree works; seems like a good idea.