RFR: 8253086: Optimization of removeAll and retainAll of ObservableListWrapper [v4]

Kevin Rushforth kcr at openjdk.java.net
Fri Oct 9 13:40:09 UTC 2020


On Fri, 9 Oct 2020 05:31:54 GMT, yosbits <github.com+7517141+yososs at openjdk.org> wrote:

>> Before I review the actual proposed change, I have a pair of related high-level questions that I should have asked at
>> the beginning of this review.
>> 1. What is the expected performance gain, and under what conditions would you see the gain?
>> 2. Do you have a program that demonstrates / measures the performance gain?
>> 
>> It doesn't need to be something that would be suitable for including as part of the PR, but we will need some test
>> program that shows enough of a performance gain to justify making this change.
>
> The performance improvements of the first change were self-evident, but
> I agree that the current changes need to be explained.
> 
> BitSet Features
> * When using BitSet, memory usage (N/8) is wasted in the case of removing the last one in the list. This is often caused
>   by user actions.
> 
> PR Features
> * The proposal records the run length of the flag, so the memory usage can be kept small in the case of consecutive
>   deletion indexes. The worst case is the case where the deletion indexes are not contiguous, which results in 4*N memory
>   consumption, but this happens very rarely. It's also the same as the memory usage of getSelectedIndices(). (Memory
>   usage is further improved by setting it to int[]).
> * Also, the delete loop is less CPU intensive and faster than BitSet's flag scan.
> 
> I will attach a test, but you'll have to wait until my next leisure time.

I understand that this will improve the performance of this method in some cases (but not all as you correctly point
out), but what I really meant by my questions was: When does this matter to an application's overall performance and
what is the performance gain you would expect to see?

As a general rule, we do not make this sort of performance optimization without a compelling reason. Improving the
performance of a method is not by itself compelling unless there is a demonstrable (not theoretical) improvement to
applications. I look forward to seeing the test program that shows the performance problem with the current
implementation and allows us to measure the improvement with your proposed patch.

-------------

PR: https://git.openjdk.java.net/jfx/pull/305


More information about the openjfx-dev mailing list