Eclipse Community Forums: Nebula » GridViewer

Help

Home

Home » Eclipse Projects » Nebula » GridViewer - Resources

Show: Today's Messages :: Show Polls :: Message Navigator

GridViewer - Resources [message #59341]

Wed, 24 September 2008 08:24

Peter Pfeifer

Messages: 98
Registered: July 2009

Member

Hello there.

We are just investigating the resource usage of the GridViewer. And our
test case uses 400k records. Ok now somebody could say, who the hell
needs 400k records at all? Well I also would say thats insane, but
unfortunately the customers requires it.

When displaying 400k records this single table uses about 700MB heap
space. So with in an RCP application thats not a valid approach, since
more than one editor can be opened.

Is there a way ti get the GridViewer to use less resources, eg with
paging or even better a sliding window as the CompositeTable does,
because some GridViewer-features are very cool, and it would be a pitty
if it can't be used in large database applications.

Regards,

Peter

Report message to a moderator

Re: GridViewer - Resources [message #59441 is a reply to message #59341]

Wed, 24 September 2008 21:34

Thomas Schindl

Messages: 6651
Registered: July 2009

Senior Member

Hi Peter,

Well the current Grid-Design is that a GridItem for every row you show
is created. So you have 400.000 Items if you want or not :-(. The
question now is the problem the data that is stored in the GridItem
(e.g. the many many strings, ....)?

Does the Grid also consume so many resources if you return and empty
string for all Labels? If it doesn't then Grid since about a week
provides a cool new feature where it informs you about the change of the
visible cells (the initial intention of this feature was to manage
Image-Handles but it could be used to clean your items string data).

The new features are part of an extra branch named "header_footer" in CVS.

Tom

Peter Pfeifer schrieb:
> Hello there.
>
> We are just investigating the resource usage of the GridViewer. And our
> test case uses 400k records. Ok now somebody could say, who the hell
> needs 400k records at all? Well I also would say thats insane, but
> unfortunately the customers requires it.
>
> When displaying 400k records this single table uses about 700MB heap
> space. So with in an RCP application thats not a valid approach, since
> more than one editor can be opened.
>
> Is there a way ti get the GridViewer to use less resources, eg with
> paging or even better a sliding window as the CompositeTable does,
> because some GridViewer-features are very cool, and it would be a pitty
> if it can't be used in large database applications.
>
> Regards,
>
> Peter

--
B e s t S o l u t i o n . at
------------------------------------------------------------ --------
Tom Schindl JFace-Committer
------------------------------------------------------------ --------

Report message to a moderator

Re: GridViewer - Resources [message #59492 is a reply to message #59441]

Fri, 26 September 2008 07:17

Peter Pfeifer

Messages: 98
Registered: July 2009

Member

Hi Tom,

Would it be also possible to remove the propertychange support and all
the things needed for databinding, when the items aren't displayed?

This would also help to save a lot of resources...

Thx,

Peter

Tom Schindl schrieb:
> Hi Peter,
>
> Well the current Grid-Design is that a GridItem for every row you show
> is created. So you have 400.000 Items if you want or not :-(. The
> question now is the problem the data that is stored in the GridItem
> (e.g. the many many strings, ....)?
>
> Does the Grid also consume so many resources if you return and empty
> string for all Labels? If it doesn't then Grid since about a week
> provides a cool new feature where it informs you about the change of the
> visible cells (the initial intention of this feature was to manage
> Image-Handles but it could be used to clean your items string data).
>
> The new features are part of an extra branch named "header_footer" in CVS.
>
> Tom
>
> Peter Pfeifer schrieb:
>> Hello there.
>>
>> We are just investigating the resource usage of the GridViewer. And our
>> test case uses 400k records. Ok now somebody could say, who the hell
>> needs 400k records at all? Well I also would say thats insane, but
>> unfortunately the customers requires it.
>>
>> When displaying 400k records this single table uses about 700MB heap
>> space. So with in an RCP application thats not a valid approach, since
>> more than one editor can be opened.
>>
>> Is there a way ti get the GridViewer to use less resources, eg with
>> paging or even better a sliding window as the CompositeTable does,
>> because some GridViewer-features are very cool, and it would be a pitty
>> if it can't be used in large database applications.
>>
>> Regards,
>>
>> Peter
>
>

Report message to a moderator

Re: GridViewer - Resources [message #59612 is a reply to message #59492]

Sun, 28 September 2008 15:17

Thomas Schindl

Messages: 6651
Registered: July 2009

Senior Member

Maybe use the POJOObservables instead? If you always go from View to
Model it is not needed!

Tom

Peter Pfeifer schrieb:
> Hi Tom,
>
> Would it be also possible to remove the propertychange support and all
> the things needed for databinding, when the items aren't displayed?
>
> This would also help to save a lot of resources...
>
> Thx,
>
> Peter
>
> Tom Schindl schrieb:
>> Hi Peter,
>>
>> Well the current Grid-Design is that a GridItem for every row you show
>> is created. So you have 400.000 Items if you want or not :-(. The
>> question now is the problem the data that is stored in the GridItem
>> (e.g. the many many strings, ....)?
>>
>> Does the Grid also consume so many resources if you return and empty
>> string for all Labels? If it doesn't then Grid since about a week
>> provides a cool new feature where it informs you about the change of the
>> visible cells (the initial intention of this feature was to manage
>> Image-Handles but it could be used to clean your items string data).
>>
>> The new features are part of an extra branch named "header_footer" in
>> CVS.
>>
>> Tom
>>
>> Peter Pfeifer schrieb:
>>> Hello there.
>>>
>>> We are just investigating the resource usage of the GridViewer. And our
>>> test case uses 400k records. Ok now somebody could say, who the hell
>>> needs 400k records at all? Well I also would say thats insane, but
>>> unfortunately the customers requires it.
>>>
>>> When displaying 400k records this single table uses about 700MB heap
>>> space. So with in an RCP application thats not a valid approach, since
>>> more than one editor can be opened.
>>>
>>> Is there a way ti get the GridViewer to use less resources, eg with
>>> paging or even better a sliding window as the CompositeTable does,
>>> because some GridViewer-features are very cool, and it would be a pitty
>>> if it can't be used in large database applications.
>>>
>>> Regards,
>>>
>>> Peter
>>
>>
>

--
B e s t S o l u t i o n . at
------------------------------------------------------------ --------
Tom Schindl JFace-Committer
------------------------------------------------------------ --------

Report message to a moderator

Re: GridViewer - Resources [message #59636 is a reply to message #59612]

Mon, 29 September 2008 10:31

Thomas Schindl

Messages: 6651
Registered: July 2009

Senior Member

Hi,

I think you can have both the only thing you need to do is to use a
special modified list as input to the observable map and not the one
you'll receive from the content provider.

This list has to be modified depending informations you receive from the
Grid with its new API and when a new value row is shown also call
viewer#update(). This way you only have PropertyChangeListener for the
currently active rows.

I'll try to create an example implementation for you when I have time.

Tom

Tom Schindl schrieb:
> Maybe use the POJOObservables instead? If you always go from View to
> Model it is not needed!
>
> Tom
>
> Peter Pfeifer schrieb:
>> Hi Tom,
>>
>> Would it be also possible to remove the propertychange support and all
>> the things needed for databinding, when the items aren't displayed?
>>
>> This would also help to save a lot of resources...
>>
>> Thx,
>>
>> Peter
>>
>> Tom Schindl schrieb:
>>> Hi Peter,
>>>
>>> Well the current Grid-Design is that a GridItem for every row you show
>>> is created. So you have 400.000 Items if you want or not :-(. The
>>> question now is the problem the data that is stored in the GridItem
>>> (e.g. the many many strings, ....)?
>>>
>>> Does the Grid also consume so many resources if you return and empty
>>> string for all Labels? If it doesn't then Grid since about a week
>>> provides a cool new feature where it informs you about the change of the
>>> visible cells (the initial intention of this feature was to manage
>>> Image-Handles but it could be used to clean your items string data).
>>>
>>> The new features are part of an extra branch named "header_footer" in
>>> CVS.
>>>
>>> Tom
>>>
>>> Peter Pfeifer schrieb:
>>>> Hello there.
>>>>
>>>> We are just investigating the resource usage of the GridViewer. And our
>>>> test case uses 400k records. Ok now somebody could say, who the hell
>>>> needs 400k records at all? Well I also would say thats insane, but
>>>> unfortunately the customers requires it.
>>>>
>>>> When displaying 400k records this single table uses about 700MB heap
>>>> space. So with in an RCP application thats not a valid approach, since
>>>> more than one editor can be opened.
>>>>
>>>> Is there a way ti get the GridViewer to use less resources, eg with
>>>> paging or even better a sliding window as the CompositeTable does,
>>>> because some GridViewer-features are very cool, and it would be a pitty
>>>> if it can't be used in large database applications.
>>>>
>>>> Regards,
>>>>
>>>> Peter
>>>
>
>

--
B e s t S o l u t i o n . at
------------------------------------------------------------ --------
Tom Schindl JFace-Committer
------------------------------------------------------------ --------

Report message to a moderator

Re: GridViewer - Resources [message #59755 is a reply to message #59636]

Tue, 30 September 2008 05:04

Peter Pfeifer

Messages: 98
Registered: July 2009

Member

Hi Tom.

Thank you very much for your answer. Take your time, i'll wait for the
example implementation.

Greeting to Tyrol.

Peter

Tom Schindl schrieb:
> Hi,
>
> I think you can have both the only thing you need to do is to use a
> special modified list as input to the observable map and not the one
> you'll receive from the content provider.
>
> This list has to be modified depending informations you receive from the
> Grid with its new API and when a new value row is shown also call
> viewer#update(). This way you only have PropertyChangeListener for the
> currently active rows.
>
> I'll try to create an example implementation for you when I have time.
>
> Tom
>
> Tom Schindl schrieb:
>> Maybe use the POJOObservables instead? If you always go from View to
>> Model it is not needed!
>>
>> Tom
>>
>> Peter Pfeifer schrieb:
>>> Hi Tom,
>>>
>>> Would it be also possible to remove the propertychange support and all
>>> the things needed for databinding, when the items aren't displayed?
>>>
>>> This would also help to save a lot of resources...
>>>
>>> Thx,
>>>
>>> Peter
>>>
>>> Tom Schindl schrieb:
>>>> Hi Peter,
>>>>
>>>> Well the current Grid-Design is that a GridItem for every row you show
>>>> is created. So you have 400.000 Items if you want or not :-(. The
>>>> question now is the problem the data that is stored in the GridItem
>>>> (e.g. the many many strings, ....)?
>>>>
>>>> Does the Grid also consume so many resources if you return and empty
>>>> string for all Labels? If it doesn't then Grid since about a week
>>>> provides a cool new feature where it informs you about the change of the
>>>> visible cells (the initial intention of this feature was to manage
>>>> Image-Handles but it could be used to clean your items string data).
>>>>
>>>> The new features are part of an extra branch named "header_footer" in
>>>> CVS.
>>>>
>>>> Tom
>>>>
>>>> Peter Pfeifer schrieb:
>>>>> Hello there.
>>>>>
>>>>> We are just investigating the resource usage of the GridViewer. And our
>>>>> test case uses 400k records. Ok now somebody could say, who the hell
>>>>> needs 400k records at all? Well I also would say thats insane, but
>>>>> unfortunately the customers requires it.
>>>>>
>>>>> When displaying 400k records this single table uses about 700MB heap
>>>>> space. So with in an RCP application thats not a valid approach, since
>>>>> more than one editor can be opened.
>>>>>
>>>>> Is there a way ti get the GridViewer to use less resources, eg with
>>>>> paging or even better a sliding window as the CompositeTable does,
>>>>> because some GridViewer-features are very cool, and it would be a pitty
>>>>> if it can't be used in large database applications.
>>>>>
>>>>> Regards,
>>>>>
>>>>> Peter
>>
>
>

Report message to a moderator