[REVIEW REQUEST] Improvements to TableView sorting
jonathan.giles at oracle.com
Tue Feb 19 14:49:08 PST 2013
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:
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
> 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).
More information about the openjfx-dev