On Mon, 18 May 2026 22:10:13 GMT, Andy Goryachev <[email protected]> wrote:
>> 1. No - but when we are only sorting (permutation) the list, the >> `ensureSize` should be a noop, since the size had to be increased at some >> point in the past to what we currently have and ensured the size >> 2. No - because a sub change temporarily adds an element which is later >> removed on another sub change. We unfortunately can not predict that/count >> that in beforehand in this `ensureSize` call. With that said, the second >> call in `addRemove` should happen very rarely - probably only with small >> sizes >> 3. It can. When we change an item, lets say A -> B and A is filtered out but >> B is not, we grow in size by 1 (or the other way around). But same as in the >> `permutation`,- the `ensureSize` should be a noop, since the size had to be >> increased at some point in the past to what we currently have and ensured >> the size > > So, while I agree that it's likely to be a no-op, my original comment did > pointed out a possible optimization (not that it will give us megabytes or > free space or 10% less CPU consumption). > > So in cases 1) and 2) we could call `ensureSize()` only when needed. It's up > to you whether you want to pursue this further or leave as is. Yeah I thought about it as well - but this is very hard to balance. We reserve quite much space here. If we have 1000 elements, we reserve space for 1501 elements. That's huge. And we are in `FilteredList` - so the normal usecase is probably with quite a few elements filtered out. But on the other hand growing in size just a few times is much better performance-wise vs. growing in size many more times. As I found out here already: https://github.com/openjdk/jfx/pull/758 ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/2163#discussion_r3262531742
