Skip to main content


Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Eclipse Projects » JFace » Performance Problems with an IObservableMap and TreeViewer
Performance Problems with an IObservableMap and TreeViewer [message #1008206] Mon, 11 February 2013 13:14 Go to next message
Timur Achmetow is currently offline Timur AchmetowFriend
Messages: 38
Registered: April 2012
Member
Hello,

I have some performance problems with my TreeViewer and an IObservableMap.
Here some piece of code:
String[] MODEL_VALUES = {Here are thirty model strings};
ObservableListTreeContentProvider contentProvider = new ObservableListTreeContentProvider();
final IObservableMap[] observeMaps = BeansObservables.observeMaps(contentProvider.getKnownElements(), MODEL_VALUES);

createColumns(.....) // I have round about 15 columns
column.setLabelProvider(new ObservableMapCellLabelProvider(observeMaps)); // set each ColumnLabelProvider


I have with this implementation some performance problems, when I load bigger models.
At the moment I have about 40 levels in the tree and each level have about 30 childrens, round about 1k items.

The tree needs 190 seconds for displaying the data.
I think this is too much and not nice for the user.

I have assert that the "IObservableMap[] observeMaps" the problem is, but why?
What I have to do btw. what I do false?
Re: Performance Problems with an IObservableMap and TreeViewer [message #1008264 is a reply to message #1008206] Mon, 11 February 2013 13:51 Go to previous messageGo to next message
Thomas Schindl is currently offline Thomas SchindlFriend
Messages: 6651
Registered: July 2009
Senior Member
Did you try building your Viewer with plain labelproviders?
JFace-Databinding leads to a huge amout of listners, but that would be
explain your extrem load time > 3 minutes.

Another problem could be that your not calculating your child-items lazy
and so all of them are loaded from your backing store and not defer it
until the node is really expanded.

http://tomsondev.bestsolution.at/2011/10/07/jface-viewer-and-eclipse-databinding-with-10-000-objects/

Tom


Am 11.02.13 14:14, schrieb Tim A.:
> Hello,
>
> I have some performance problems with my TreeViewer and an IObservableMap.
> Here some piece of code:
>
> String[] MODEL_VALUES = {Here are thirty model strings};
> ObservableListTreeContentProvider contentProvider = new
> ObservableListTreeContentProvider();
> final IObservableMap[] observeMaps =
> BeansObservables.observeMaps(contentProvider.getKnownElements(),
> MODEL_VALUES);
>
> createColumns(.....) // I have round about 15 columns
> column.setLabelProvider(new
> ObservableMapCellLabelProvider(observeMaps)); // set each
> ColumnLabelProvider
>
>
> I have with this implementation some performance problems, when I load
> bigger models.
> At the moment I have about 40 levels in the tree and each level have
> about 30 childrens, round about 1k items.
> The tree needs 190 seconds for displaying the data. I think this is too
> much and not nice for the user.
> I have assert that the "IObservableMap[] observeMaps" the problem is,
> but why?
> What I have to do btw. what I do false?
Re: Performance Problems with an IObservableMap and TreeViewer [message #1008406 is a reply to message #1008264] Tue, 12 February 2013 11:13 Go to previous messageGo to next message
Nigel Westbury is currently offline Nigel WestburyFriend
Messages: 18
Registered: July 2009
Junior Member
In my opinion the problem really comes down to the fact that JavaBeans
itself is not scalable. Requiring a listener to be added to every bean
seems an odd decision to me. When I created the framework for a model
layer about 9 years ago (pre-databinding days) I instinctively (i.e.
without much thought) created a single listener for all changes in the
model. I have thought about whether that should be changed to bring
into line with JavaBeans as I am generally a proponent of following
commonly used patterns. However in this case I am glad I did not.

Adding listeners only on elements that are currently visible certainly
helps. However that is a solution only to the particular problem of
elements in a Nebula table. It is also not a great solution because
elements are stale as they are scrolled into view.

Databinding is not dependent on JavaBeans, that being just one pattern
for which an implementation is provided. So it should be possible to
use databinding with a model that has a different listener architecture.
However the problem is that the API for databinding is very much
centered around the idea of adding a separate listener to each element,
so we do need to re-jiggle the internal databinding code to support this.

So the current code, copied from Tom's blog:

column.setLabelProvider(new ObservableMapCellLabelProvider(

BeanProperties.value("firstname").observeDetail(cp.getKnownElements())
)
);

might then become:

column.setLabelProvider(new ObservableMapCellLabelProvider(
valueProperty.observeDetail(cp.getKnownElements(), elementContainer)
)
);

This is much the same but there is an elementContainer which would
implement a method called something like
addPropertyChangeListener(valueProperty, listener) which fires when the
property value changes in any object. Alternatively perhaps the
implementation of valueProperty should keep the reference to
elementContainer. That way the API is much the same though changes
would be needed internally to databinding.

Anyway, I just wanted to put the idea out there, and I certainly think
we should make sure that this issue gets addressed as part of the
planned changes to the databinding API. Keep your tests around, Tom, so
we can see what figures we get after these changes!

Nigel Westbury

On 11/02/2013 13:51, Tom Schindl wrote:
> Did you try building your Viewer with plain labelproviders?
> JFace-Databinding leads to a huge amout of listners, but that would be
> explain your extrem load time > 3 minutes.
>
> Another problem could be that your not calculating your child-items lazy
> and so all of them are loaded from your backing store and not defer it
> until the node is really expanded.
>
> http://tomsondev.bestsolution.at/2011/10/07/jface-viewer-and-eclipse-databinding-with-10-000-objects/
>
> Tom
>
>
> Am 11.02.13 14:14, schrieb Tim A.:
>> Hello,
>>
>> I have some performance problems with my TreeViewer and an IObservableMap.
>> Here some piece of code:
>>
>> String[] MODEL_VALUES = {Here are thirty model strings};
>> ObservableListTreeContentProvider contentProvider = new
>> ObservableListTreeContentProvider();
>> final IObservableMap[] observeMaps =
>> BeansObservables.observeMaps(contentProvider.getKnownElements(),
>> MODEL_VALUES);
>>
>> createColumns(.....) // I have round about 15 columns
>> column.setLabelProvider(new
>> ObservableMapCellLabelProvider(observeMaps)); // set each
>> ColumnLabelProvider
>>
>>
>> I have with this implementation some performance problems, when I load
>> bigger models.
>> At the moment I have about 40 levels in the tree and each level have
>> about 30 childrens, round about 1k items.
>> The tree needs 190 seconds for displaying the data. I think this is too
>> much and not nice for the user.
>> I have assert that the "IObservableMap[] observeMaps" the problem is,
>> but why?
>> What I have to do btw. what I do false?
>
Re: Performance Problems with an IObservableMap and TreeViewer [message #1009473 is a reply to message #1008264] Fri, 15 February 2013 07:47 Go to previous messageGo to next message
Timur Achmetow is currently offline Timur AchmetowFriend
Messages: 38
Registered: April 2012
Member
Thomas Schindl wrote on Mon, 11 February 2013 08:51

Did you try building your Viewer with plain labelproviders?
JFace-Databinding leads to a huge amout of listners, but that would be
explain your extrem load time > 3 minutes.


I have used ObservableMapCellLabelProvider for each column.

Quote:

Another problem could be that your not calculating your child-items lazy
and so all of them are loaded from your backing store and not defer it
until the node is really expanded.


Yes maybe, an alternative is SWT.Virtual with a LazyTreeContentProvider.
Re: Performance Problems with an IObservableMap and TreeViewer [message #1009480 is a reply to message #1008406] Fri, 15 February 2013 08:06 Go to previous messageGo to next message
Timur Achmetow is currently offline Timur AchmetowFriend
Messages: 38
Registered: April 2012
Member
Nigel Westbury wrote on Tue, 12 February 2013 06:13

In my opinion the problem really comes down to the fact that JavaBeans
itself is not scalable. Requiring a listener to be added to every bean
seems an odd decision to me. When I created the framework for a model
layer about 9 years ago (pre-databinding days) I instinctively (i.e.
without much thought) created a single listener for all changes in the
model.


Yes right, I have solved my problem with one listener, too.
I have added only one listener for each element and not for each property.
This listener observes the whole changes from this element.

Quote:

Databinding is not dependent on JavaBeans, that being just one pattern
for which an implementation is provided. So it should be possible to
use databinding with a model that has a different listener architecture.
However the problem is that the API for databinding is very much
centered around the idea of adding a separate listener to each element,
so we do need to re-jiggle the internal databinding code to support this.

So the current code, copied from Tom's blog:

column.setLabelProvider(new ObservableMapCellLabelProvider(

BeanProperties.value("firstname").observeDetail(cp.getKnownElements())
)
);

might then become:

column.setLabelProvider(new ObservableMapCellLabelProvider(
valueProperty.observeDetail(cp.getKnownElements(), elementContainer)
)
);

This is much the same but there is an elementContainer which would
implement a method called something like
addPropertyChangeListener(valueProperty, listener) which fires when the
property value changes in any object. Alternatively perhaps the
implementation of valueProperty should keep the reference to
elementContainer. That way the API is much the same though changes
would be needed internally to databinding.


Right, I think this is a great idea for the JFace-API.
Make it sense to open a bug entry for this problem?
Re: Performance Problems with an IObservableMap and TreeViewer [message #1010601 is a reply to message #1009480] Sun, 17 February 2013 20:37 Go to previous messageGo to next message
Nigel Westbury is currently offline Nigel WestburyFriend
Messages: 18
Registered: July 2009
Junior Member
I didn't mean 'one listener per element that covers all properties', I
meant 'one listener per property that covers all elements'. Java Beans
supports the first but not the second. The first helps a little but
still does not scale.

I have published an example of how you can use ViewerSupport.bind to
bind your labels in a scalable manner. The example creates one listener
per property (table column) regardless of how many elements there are.
I have documented this at nwestbury.wordpress.com. This example uses
the databinding plug-ins as is but the example could be simplified if
the databinding classes were refactored a little.

Nigel Westbury

On 15/02/2013 08:06, Tim A. wrote:
> Nigel Westbury wrote on Tue, 12 February 2013 06:13
>> In my opinion the problem really comes down to the fact that JavaBeans
>> itself is not scalable. Requiring a listener to be added to every
>> bean seems an odd decision to me. When I created the framework for a
>> model layer about 9 years ago (pre-databinding days) I instinctively
>> (i.e. without much thought) created a single listener for all changes
>> in the model.
>
>
> Yes right, I have solved my problem with one listener, too. I have added
> only one listener for each element and not for each property. This
> listener observes the whole changes from this element.
> Quote:
>> Databinding is not dependent on JavaBeans, that being just one pattern
>> for which an implementation is provided. So it should be possible to
>> use databinding with a model that has a different listener
>> architecture. However the problem is that the API for databinding is
>> very much centered around the idea of adding a separate listener to
>> each element, so we do need to re-jiggle the internal databinding code
>> to support this.
>>
>> So the current code, copied from Tom's blog:
>>
>> column.setLabelProvider(new ObservableMapCellLabelProvider(
>>
>> BeanProperties.value("firstname").observeDetail(cp.getKnownElements())
>> )
>> );
>>
>> might then become:
>>
>> column.setLabelProvider(new ObservableMapCellLabelProvider(
>> valueProperty.observeDetail(cp.getKnownElements(),
>> elementContainer)
>> )
>> );
>>
>> This is much the same but there is an elementContainer which would
>> implement a method called something like
>> addPropertyChangeListener(valueProperty, listener) which fires when
>> the property value changes in any object. Alternatively perhaps the
>> implementation of valueProperty should keep the reference to
>> elementContainer. That way the API is much the same though changes
>> would be needed internally to databinding.
>
>
> Right, I think this is a great idea for the JFace-API.
> Make it sense to open a bug entry for this problem?
>
Re: Performance Problems with an IObservableMap and TreeViewer [message #1010965 is a reply to message #1010601] Mon, 18 February 2013 15:18 Go to previous message
Timur Achmetow is currently offline Timur AchmetowFriend
Messages: 38
Registered: April 2012
Member
Nigel Westbury wrote on Sun, 17 February 2013 15:37

I didn't mean 'one listener per element that covers all properties', I
meant 'one listener per property that covers all elements'.


Ah okay, now I understand. Yes this solution is also very nice.

Quote:

I have published an example of how you can use ViewerSupport.bind to
bind your labels in a scalable manner. The example creates one listener
per property (table column) regardless of how many elements there are.
I have documented this at nwestbury.wordpress.com.


Hey Nigel, that's a very nice code snippet.
It looks easy and the performance is also nice. Great job!
Previous Topic:WritableList casting issues
Next Topic:CoolBarManager/ToolBarManager with contributionItems
Goto Forum:
  


Current Time: Fri Apr 19 02:37:24 GMT 2024

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

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

Back to the top