[REVIEW REQUEST] Improvements to TableView sorting

[Jonathan Giles]

On 20/02/2013 12:37 a.m., John Hendrikx wrote:
> I have a few questions, most are related to this use case:
>
> Have a huge list (say a million items), sort it, user shift selects 
> the top half a million items (0-500000), now sort it again on some 
> unrelated criteria (making the distribution of selected items random) 
> and now remove those items (user presses delete). It's important none 
> of those actions slow the system down to a crawl (it will kill the 
> Swing implementation).  Possible performance problems:
>
> - Transforming a select range of 0-500000 to many smaller select 
> ranges when a resort occurs
I have a Jira tracking selection model performance improvements:
http://javafx-jira.kenai.com/browse/RT-10034

I don't want to delve too deeply into this (as the high-level answer is 
that of course performance is critical, we need to be conscious of it, 
and we have a performance team that have special performance tests that 
ensure we don't have regressions here). However, in summary, at present 
ListView and TreeView use a BitSet-based selection model (where each bit 
represents a row where 0 = unselected and 1 = selected). TableView and 
TreeTableView, on the other hand, use a slightly more archaic 
ArrayList-based selection model (where the ArrayList is populated with 
TablePosition instances representing a single row or row/column 
position). Ideally we would transition towards a more optimised and 
performant implementation as soon as possible, but I've not done 
extensive research into what the best options are.

I would happily accept alternate selection model implementations if 
anyone is interested in writing them :-)

> - Huge 'mapping' arrays being used with "before" and "after" sort 
> states for keeping track of selection
I'm not entirely clear what it is you're saying here.

> - Depending on the backing list, many random deletes in a huge List 
> will be costly (ArrayList won't cut it, any Events being triggered on 
> modification of the list will likely also introduce a huge 
> bottleneck).  Note that the use case specifically causes these deletes 
> to be random!  It's not possible to do it in a single remove event.
> - Resorting after every list change
>
> 1) Does SortedList force a specific type of List implementation, or is 
> it an Interface?
I will leave this to Martin to answer.
> 2) How is the change of sort order communicated to the Selection 
> Model? Will it be possible to override the selection model with a 
> custom implementation (one that is sort order independent for example) 
> without incurring overhead from unnecessary selection model updates 
> caused by sorting?
Selection Model watches the items list for changes and reacts 
accordingly. You are more than welcome to install a custom selection 
model, but then of course the onus is on you to maintain the selection 
for the control.
>
> I like the flexibility provided:
>
> SortEvent seems to cover the option of creating an (external) 
> implementation of sorting yourself should there be performance problems.
>
> SortPolicy -- if I understand correctly -- externalizes the entire 
> sorting (and filtering?) mechanism, similar to what the SelectionModel 
> and FocusModel do.  This keeps the View classes cleaner (they're quite 
> complex already) and more focused on their tasks of managing Cells and 
> navigation between cells.  You call it a Callback, does that mean it 
> instantiates something or is just an interface?
Callback is a commonly-used interface in the JavaFX world. Put simply it 
is a single-method interface that accepts one argument into the method, 
and returns a value. In this case we have a sortPolicy Callback that 
takes a TableView (or TreeTableView) and returns a Boolean to represent 
success of failure (although this API may change when I get around to 
implementation).
>
> The only thing for now that I think smells a bit is the special case 
> for SortedList.  Is this hidden away in the SortPolicy or will it 
> touch the View classes as well?
>
This is unclear yet and a topic for further discussion (although in 
general it will not be something that a developer should ever concern 
themselves with or necessarily even see).

-- Jonathan