Skip to main content


Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Eclipse Projects » NatTable » SelectionLayer and SelectionModel: Performance troubles
SelectionLayer and SelectionModel: Performance troubles [message #1267855] Sun, 09 March 2014 17:46 Go to next message
Michael Heiß is currently offline Michael HeißFriend
Messages: 19
Registered: November 2013
Location: Graz, Austria
Junior Member
Hi,

We recently had some severe performance problems when a large amount of cells are selected (> 10.000 selected cells in a table with 1.000 lines and 10 columns). I had a quick look at the SelectionModel and discovered that the selected cells are kept in a list. So basically the determination whether a given cell is selected is extremely expensive. In the worst case all elements have to be inspected to determine that a given cell is or is not selected.

I came up with the idea to write a new SelectionModel that tracks the selections in a map. Lookup would be cheaper and the performance would not be influenced by the number of selected cells. However I stumbled across a major problem while doing this:

The SelectionLayer DIRECTLY modifies the last rectangle added to the SelectionModel.

Let me explain this a little bit more detailed with the API calls that are made against the model when doing a selection. Given a table with a single row and two columns:

Cell 1 Cell 2
---------------------
| x=0,y=0 | x=1,y=0 |
---------------------

*) Select the first cell by clicking on it:
ISelectionModel#addSelection with a rectangle {0, 0, 1, 1} is called as expected.

*) Without releasing the mouse move the cursor to the next cell:
ISelectionModel#addSelection with a rectangle {0, 0, 2, 1} is called. This is a little bit surprising since I would expect to get only the new rectangle {1, 0, 1, 1} but that's OK.

BUG: The SelectionModel now has two entries (same instance): [Rectangle {0, 0, 2, 1} AND Rectangle {0, 0, 2, 1}]

*) Again without releasing the mouse move the cursor back to the first cell.
ISelectionModel#addSelection with a rectangle {0, 0, 1, 1} is called. Now this is really surprising since I would expect a call against ISelectionModel#clearSelection with the removed cell.

Bug: The SelectionModel now has three entries (all the same instance): [Rectangle {0, 0, 1, 1}, Rectangle {0, 0, 1, 1} AND Rectangle {0, 0, 1, 1}].

Basically nobody tells the model to remove the now non selected cell. This is only working as the SelectionModel directly modifies the rectangle that is stored in the list of the selection model. When the model would store a copy of the rectangle and not the same instance that is passed it would stop working. Is the observed behavior a bug or has this been implemented intentionally?

Just as information why we are doing this: We are calling ISelectionModel#getSelectedRowPositions to attach a label to each cell if at least one cell in the same row is selected. This causes severe performance troubles when a large amount of cells is selected. We could find a workaround for this single place but there are more calls against the selection layer... They would all benefit from a faster implementation that does less calculations for all the provided getters.

Any suggestions how to go on with my custom implementation?

Regards
Michael
Re: SelectionLayer and SelectionModel: Performance troubles [message #1268229 is a reply to message #1267855] Mon, 10 March 2014 08:14 Go to previous messageGo to next message
Dirk Fauth is currently offline Dirk FauthFriend
Messages: 2703
Registered: July 2012
Senior Member
Quote:
Is the observed behavior a bug or has this been implemented intentionally?


How I love that question! First, as selection works fine, it can't be a bug. A bug is per definition something that doesn't work or doesn't work correctly.

If it is implemented that way intentionally? Well I guess so. The default selection behaviour works fine. If the developer had your use case in mind or whatever, I'm not sure. AFAIK there is no perfect software and there is always space for improvement.

The direct modification of states is really something that we don't like now. When NatTable was created, the developers might have thought it would be a good idea. And it works ok, but you noticed a possible issue with mutable states. We will consider this for the next architecture.

Quote:
(> 10.000 selected cells in a table with 1.000 lines and 10 columns)


If my math skills are not too bad, it is not possible to select more than 10.000 cells in a table with 1.000 lines and 10 columns. Wink

Quote:
We are calling ISelectionModel#getSelectedRowPositions to attach a label to each cell if at least one cell in the same row is selected


Not sure about your implementation, but it looks like you are calling getSelectedRowPositions() for every cell that is rendered. And it is always time consuming when you are calling code that needs its time a lot of times.

Quote:
Any suggestions how to go on with my custom implementation?


No. But why don't you modify your IConfigLabelAccumulator to cache the selected row positions? And refresh the cache whenever the selection changes? Seems to me the better way.
Re: SelectionLayer and SelectionModel: Performance troubles [message #1268282 is a reply to message #1268229] Mon, 10 March 2014 09:44 Go to previous messageGo to next message
Michael Heiß is currently offline Michael HeißFriend
Messages: 19
Registered: November 2013
Location: Graz, Austria
Junior Member
As stated we could do workarounds but this is really a bad idea since there are more parts wich are affected by the bad performance of this layer. I will try to resolve this within my implementation.
Re: SelectionLayer and SelectionModel: Performance troubles [message #1268299 is a reply to message #1268282] Mon, 10 March 2014 10:12 Go to previous message
Dirk Fauth is currently offline Dirk FauthFriend
Messages: 2703
Registered: July 2012
Senior Member
Quote:
there are more parts wich are affected by the bad performance of this layer


That depends on your use cases. For the default cases I know, the performance is ok. But as I said before, there is always room for improvement.

Knowing that I repeat myself often, I am a consultant and will do sponsored development in such special cases. Wink
Previous Topic:Force editing programmatically
Next Topic:Question about the ViewportLayer moveColumnPositionIntoViewport method
Goto Forum:
  


Current Time: Thu Aug 22 01:19:52 GMT 2019

Powered by FUDForum. Page generated in 0.06710 seconds
.:: Contact :: Home ::.

Powered by: FUDforum 3.0.2.
Copyright ©2001-2010 FUDforum Bulletin Board Software

Back to the top