|
|
Re: Performance Problems with an IObservableMap and TreeViewer [message #1008406 is a reply to message #1008264] |
Tue, 12 February 2013 11:13 |
Nigel Westbury 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 #1009480 is a reply to message #1008406] |
Fri, 15 February 2013 08:06 |
Timur Achmetow 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 |
Nigel Westbury 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?
>
|
|
|
|
Powered by
FUDForum. Page generated in 0.02683 seconds