Home » Modeling » EMF » [CDO/Databinding] "The Databinding / CDO Tango" Can we dance a bit faster please
| [CDO/Databinding] "The Databinding / CDO Tango" Can we dance a bit faster please [message #757963] |
Fri, 18 November 2011 09:40  |
 Christophe Bouhier
Messages: 937
Registered: July 2009 |
Senior Member |
|
|
Hi,
Our App is ready, and after loading more and more data it turns out it
takes too long (> 10 seconds) to load some of the screens.
The application stack looks roughly like this:
- JFace TableViewer
- EMF/JFace Databinding
- CDO Client
- Objects to resource mapping. (Our strategy is that Root classes are
stored in their own resource, the Resource name = eClass name).
- Model Packages and containment hierarchy
- CDO Store (Hibernate)
- Postgress SQL DB.
Can it be that a Single resource which is the entry point to a very
large containment hierarchy be a bottle neck?
(See the first diagram attached, with the question "Are the children
also fetched? ). Note that the LabelProvider extends
ObservableMapLabelProvider, which could be nasty and attach itself to
the whole containment tree?
Considering the dynamic lazy loading nature of CDO, I doubt it would
load the children, but perhaps I don't understand lazy loading or how it
tango's with Databinding).
Turning the question around, would I gain performance when using i.e.
cross-resource containment reference, resulting in a containment
hierarchy which is distributed over multiple CDO Resources? Or would
this be negated by the fact that the Databinding wants to be notified
for the whole tree, and there for would attach listeners to the whole
tree? (See the 2nd diagram attached).
It could also be the setup is optimal already, and the Slow server (Sun
spark on Solaris) is the culprit, slowing things down....
Finally, I also suspect that the additional Hibernate layer slows down
matters , and a native CDOStore could boost performance?
For now, I have a customer who is dissapointed on the performance for
some of the screens ....
I would greatly Appreciate any help or light on this matter.
Regards Christophe
|
|
|
| Re: [CDO/Databinding] "The Databinding / CDO Tango" Can we dance a bit faster plea [message #757964 is a reply to message #757963] |
Fri, 18 November 2011 09:57  |
Thomas Schindl
Messages: 6651
Registered: July 2009 |
Senior Member |
|
|
Hi,
a) a TableViewer and ObservableListContentProvider are very greedy so
all items are loaded and immediately rendered (in case you are not
using the Virtual-Support)!
b) ObservableMapLabelProvider will attach a listener to every single
cell (e.g. a 1000 rows * 10 columns results in 10.000 Listeners)
I've written a nice blog post how to overcome those JFace-Problems using
Nebula-Grid [1].
This only helps you if the rendering is the bottleneck. If it is loading
the objects it won't help and all you can do is to use suitable default
filters so that not so many objects get fetched and handed to the
JFace-Viewer.
Tom
[1]http://tomsondev.bestsolution.at/2011/10/07/jface-viewer-and-eclipse-databinding-with-10-000-objects/
Am 18.11.11 10:40, schrieb Christophe Bouhier:
> Hi,
>
> Our App is ready, and after loading more and more data it turns out it
> takes too long (> 10 seconds) to load some of the screens.
>
> The application stack looks roughly like this:
>
> - JFace TableViewer
> - EMF/JFace Databinding
> - CDO Client
> - Objects to resource mapping. (Our strategy is that Root classes are
> stored in their own resource, the Resource name = eClass name).
> - Model Packages and containment hierarchy
> - CDO Store (Hibernate)
> - Postgress SQL DB.
>
>
> Can it be that a Single resource which is the entry point to a very
> large containment hierarchy be a bottle neck?
> (See the first diagram attached, with the question "Are the children
> also fetched? ). Note that the LabelProvider extends
> ObservableMapLabelProvider, which could be nasty and attach itself to
> the whole containment tree?
>
> Considering the dynamic lazy loading nature of CDO, I doubt it would
> load the children, but perhaps I don't understand lazy loading or how it
> tango's with Databinding).
>
> Turning the question around, would I gain performance when using i.e.
> cross-resource containment reference, resulting in a containment
> hierarchy which is distributed over multiple CDO Resources? Or would
> this be negated by the fact that the Databinding wants to be notified
> for the whole tree, and there for would attach listeners to the whole
> tree? (See the 2nd diagram attached).
>
> It could also be the setup is optimal already, and the Slow server (Sun
> spark on Solaris) is the culprit, slowing things down....
>
> Finally, I also suspect that the additional Hibernate layer slows down
> matters , and a native CDOStore could boost performance?
>
> For now, I have a customer who is dissapointed on the performance for
> some of the screens ....
>
> I would greatly Appreciate any help or light on this matter.
>
> Regards Christophe
|
|
|
| Re: [CDO/Databinding] "The Databinding / CDO Tango" Can we dance a bit faster plea [message #757965 is a reply to message #757963] |
Fri, 18 November 2011 10:15 |
|
Am 18.11.2011 10:40, schrieb Christophe Bouhier:
> Hi,
>
> Our App is ready, and after loading more and more data it turns out it takes too long (> 10 seconds) to load some of
> the screens.
>
> The application stack looks roughly like this:
>
> - JFace TableViewer
> - EMF/JFace Databinding
> - CDO Client
> - Objects to resource mapping. (Our strategy is that Root classes are stored in their own resource, the Resource name
> = eClass name).
> - Model Packages and containment hierarchy
> - CDO Store (Hibernate)
> - Postgress SQL DB.
You should definitely use a profiler to see where the time is being spent.
>
>
> Can it be that a Single resource which is the entry point to a very large containment hierarchy be a bottle neck?
CDO does not care.
> (See the first diagram attached, with the question "Are the children also fetched? ). Note that the LabelProvider
> extends ObservableMapLabelProvider, which could be nasty and attach itself to the whole containment tree?
Unfortunately I don't quite understand the diagrams. Do they show dataflows?
>
> Considering the dynamic lazy loading nature of CDO, I doubt it would load the children, but perhaps I don't understand
> lazy loading or how it tango's with Databinding).
It's best to set a couple of breakpoints and investigate the cooperations.
Vik has developed a CDOLazyContentAdapter, maybe that helps?
>
> Turning the question around, would I gain performance when using i.e. cross-resource containment reference, resulting
> in a containment hierarchy which is distributed over multiple CDO Resources?
Very unlikely.
> Or would this be negated by the fact that the Databinding wants to be notified for the whole tree, and there for would
> attach listeners to the whole tree? (See the 2nd diagram attached).
>
> It could also be the setup is optimal already, and the Slow server (Sun spark on Solaris) is the culprit, slowing
> things down....
You must profile it. Try the hints on http://wiki.eclipse.org/CDO/Tweaking_Performance
Are you using auditing?
>
> Finally, I also suspect that the additional Hibernate layer slows down matters ,
Have you tried it?
> and a native CDOStore could boost performance?
What is a native CDOStore?
Cheers
/Eike
----
http://www.esc-net.de
http://thegordian.blogspot.com
http://twitter.com/eikestepper
Cheers
/Eike
----
http://www.esc-net.de
http://thegordian.blogspot.com
http://twitter.com/eikestepper
|
|
|
| Re: [CDO/Databinding] "The Databinding / CDO Tango" Can we dance a bit faster plea [message #757966 is a reply to message #757964] |
Fri, 18 November 2011 10:15 |
Christophe Bouhier
Messages: 937
Registered: July 2009 |
Senior Member |
|
|
Tom, Thanks for the fast response!
I wasn't are of this blog entry, will study this now.
Just to clarify:
> This only helps you if the rendering is the bottleneck. If it is loading
> the objects it won't help and all you can do is to use suitable default
> filters so that not so many objects get fetched and handed to the
> JFace-Viewer.
In my case the viewer doesn't have so many entries, just about 40. What
I wonder is, if the ObservableMapLabelProvider attaches itself to the
children in the containment hierarchy? (Forcing CDO to load the objects).
merci Christophe
On 18-11-11 10:57, Tom Schindl wrote:
> Hi,
>
> a) a TableViewer and ObservableListContentProvider are very greedy so
> all items are loaded and immediately rendered (in case you are not
> using the Virtual-Support)!
>
> b) ObservableMapLabelProvider will attach a listener to every single
> cell (e.g. a 1000 rows * 10 columns results in 10.000 Listeners)
>
> I've written a nice blog post how to overcome those JFace-Problems using
> Nebula-Grid [1].
>
> This only helps you if the rendering is the bottleneck. If it is loading
> the objects it won't help and all you can do is to use suitable default
> filters so that not so many objects get fetched and handed to the
> JFace-Viewer.
>
> Tom
>
> [1]http://tomsondev.bestsolution.at/2011/10/07/jface-viewer-and-eclipse-databinding-with-10-000-objects/
>
> Am 18.11.11 10:40, schrieb Christophe Bouhier:
>> Hi,
>>
>> Our App is ready, and after loading more and more data it turns out it
>> takes too long (> 10 seconds) to load some of the screens.
>>
>> The application stack looks roughly like this:
>>
>> - JFace TableViewer
>> - EMF/JFace Databinding
>> - CDO Client
>> - Objects to resource mapping. (Our strategy is that Root classes are
>> stored in their own resource, the Resource name = eClass name).
>> - Model Packages and containment hierarchy
>> - CDO Store (Hibernate)
>> - Postgress SQL DB.
>>
>>
>> Can it be that a Single resource which is the entry point to a very
>> large containment hierarchy be a bottle neck?
>> (See the first diagram attached, with the question "Are the children
>> also fetched? ). Note that the LabelProvider extends
>> ObservableMapLabelProvider, which could be nasty and attach itself to
>> the whole containment tree?
>>
>> Considering the dynamic lazy loading nature of CDO, I doubt it would
>> load the children, but perhaps I don't understand lazy loading or how it
>> tango's with Databinding).
>>
>> Turning the question around, would I gain performance when using i.e.
>> cross-resource containment reference, resulting in a containment
>> hierarchy which is distributed over multiple CDO Resources? Or would
>> this be negated by the fact that the Databinding wants to be notified
>> for the whole tree, and there for would attach listeners to the whole
>> tree? (See the 2nd diagram attached).
>>
>> It could also be the setup is optimal already, and the Slow server (Sun
>> spark on Solaris) is the culprit, slowing things down....
>>
>> Finally, I also suspect that the additional Hibernate layer slows down
>> matters , and a native CDOStore could boost performance?
>>
>> For now, I have a customer who is dissapointed on the performance for
>> some of the screens ....
>>
>> I would greatly Appreciate any help or light on this matter.
>>
>> Regards Christophe
>
|
|
|
| Re: [CDO/Databinding] "The Databinding / CDO Tango" Can we dance a bit faster plea [message #757967 is a reply to message #757965] |
Fri, 18 November 2011 10:27 |
Christophe Bouhier
Messages: 937
Registered: July 2009 |
Senior Member |
|
|
Hi Eike, thanks for the swift response.
- Profiling, yes but before that I need to be sure on some of the
mechanism, hence this post.
- The diagram shows the various layers... and how indeed the data flows
between them.
- CDOLazyContentAdapter, I will check it out, thanks.
- Thanks for confirming on the cross-resource containment
- I am not using auditing, I believe it's not supported by
Teneo.hibernate store.
- Native, I mean non-hibernate.
rgds Christophe
On 18-11-11 11:15, Eike Stepper wrote:
> Am 18.11.2011 10:40, schrieb Christophe Bouhier:
>> Hi,
>>
>> Our App is ready, and after loading more and more data it turns out it
>> takes too long (> 10 seconds) to load some of the screens.
>>
>> The application stack looks roughly like this:
>>
>> - JFace TableViewer
>> - EMF/JFace Databinding
>> - CDO Client
>> - Objects to resource mapping. (Our strategy is that Root classes are
>> stored in their own resource, the Resource name = eClass name).
>> - Model Packages and containment hierarchy
>> - CDO Store (Hibernate)
>> - Postgress SQL DB.
>
> You should definitely use a profiler to see where the time is being spent.
>
>>
>>
>> Can it be that a Single resource which is the entry point to a very
>> large containment hierarchy be a bottle neck?
> CDO does not care.
>
>> (See the first diagram attached, with the question "Are the children
>> also fetched? ). Note that the LabelProvider extends
>> ObservableMapLabelProvider, which could be nasty and attach itself to
>> the whole containment tree?
> Unfortunately I don't quite understand the diagrams. Do they show
> dataflows?
>
>>
>> Considering the dynamic lazy loading nature of CDO, I doubt it would
>> load the children, but perhaps I don't understand lazy loading or how
>> it tango's with Databinding).
> It's best to set a couple of breakpoints and investigate the cooperations.
>
> Vik has developed a CDOLazyContentAdapter, maybe that helps?
>
>>
>> Turning the question around, would I gain performance when using i.e.
>> cross-resource containment reference, resulting in a containment
>> hierarchy which is distributed over multiple CDO Resources?
> Very unlikely.
>
>> Or would this be negated by the fact that the Databinding wants to be
>> notified for the whole tree, and there for would attach listeners to
>> the whole tree? (See the 2nd diagram attached).
>>
>> It could also be the setup is optimal already, and the Slow server
>> (Sun spark on Solaris) is the culprit, slowing things down....
> You must profile it. Try the hints on
> http://wiki.eclipse.org/CDO/Tweaking_Performance
>
> Are you using auditing?
>
>>
>> Finally, I also suspect that the additional Hibernate layer slows down
>> matters ,
> Have you tried it?
>
>> and a native CDOStore could boost performance?
> What is a native CDOStore?
>
> Cheers
> /Eike
>
> ----
> http://www.esc-net.de
> http://thegordian.blogspot.com
> http://twitter.com/eikestepper
>
|
|
| |
Goto Forum:
Current Time: Fri Apr 26 12:34:48 GMT 2024
Powered by FUDForum. Page generated in 0.04185 seconds |
] 
Search
Help
Register
Login
Home
