Eclipse Community Forums: EMF » Problem performance getString of ItemProvider

Search

Help

Login

Home » Modeling » EMF » Problem performance getString of ItemProvider

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

Switch to threaded view of this topic

Create a new topic

Submit Reply

Problem performance getString of ItemProvider [message #496571]

Tue, 10 November 2009 15:19

David CHAUTARD is currently offline

Friend

Messages: 102
Registered: July 2009

Senior Member

Hello,
I use the Master/DetailsPage pattern in my RCP application. And when the MasterPage tree contains a lot of elements, I have a problem of performance. For exemple when I want to add a new element in the tree, the application is stick during the action, but not with some elements.
I think the problem comes from the ItemProvider of the selected element, because the methods getFeatureText and getTextType are called for all the tree elements, and for the same label. These calls take a lot of time.

Any ideas to manage these methods in order to avoid to call them more than one time for the same label?

Thx for you help,
David.

Report message to a moderator

Re: Problem performance getString of ItemProvider [message #496583 is a reply to message #496571]

Tue, 10 November 2009 15:51

Ed Merks is currently offline

Friend

Messages: 30635
Registered: July 2009

Senior Member

David,

Comments below.

David CHAUTARD wrote:
> Hello,
> I use the Master/DetailsPage pattern in my RCP application. And when
> the MasterPage tree contains a lot of elements, I have a problem of
> performance. For exemple when I want to add a new element in the
> tree, the application is stick during the action, but not with some
> elements.
> I think the problem comes from the ItemProvider of the selected
> element, because the methods getFeatureText and getTextType are called
> for all the tree elements, and for the same label. These calls take a
> lot of time.
This is used for the child creation menu items... Have you used a tool
to determine the actual bottleneck? I can't imagine why it should be
called for elements other than the selection...
>
> Any ideas to manage these methods in order to avoid to call them more
> than one time for the same label?
>
> Thx for you help,
> David.

Report message to a moderator

Re: Problem performance getString of ItemProvider [message #496589 is a reply to message #496571]

Tue, 10 November 2009 16:15

David CHAUTARD is currently offline

Friend

Messages: 102
Registered: July 2009

Senior Member

Hi Ed,

Effectively I use TPTP to determine the bottleneck. When I open my editor, these methods are call for each elements in my tree. And when I go to a tabItem in order to select an element in the tree, these methods are still called several time (always the same call number) for this element. And it is proportional to the number of elements in the tree.

David.

Report message to a moderator

Re: Problem performance getString of ItemProvider [message #496614 is a reply to message #496589]

Tue, 10 November 2009 16:47

Ed Merks is currently offline

Friend

Messages: 30635
Registered: July 2009

Senior Member

David,

Comments below.

David CHAUTARD wrote:
> Hi Ed,
>
> Effectively I use TPTP to determine the bottleneck. When I open my
> editor, these methods are call for each elements in my tree.
Not just the selection? I expect the method you mention to be called
only for populating the child creation method of the selected element...
> And when I go to a tabItem in order to select an element in the tree,
> these methods are still called several time (always the same call
> number) for this element.
That I'd expect.
> And it is proportional to the number of elements in the tree.
I'd expect it to be proportional to the types of children and the number
of selected objects. I also expect them to be fast, i.e., effectively a
mapped lookup...
>
> David.

Report message to a moderator

Re: Problem performance getString of ItemProvider [message #498276 is a reply to message #496614]

Mon, 16 November 2009 10:18

David CHAUTARD is currently offline

Friend

Messages: 102
Registered: July 2009

Senior Member

Thanks Ed,

Quote:

I'd expect it to be proportional to the types of children and the number of selected objects

You think that this behaviour in normal?
I understand that these methods are called for the selection, but I don't understand why it is done for each element of my tree, because the same treatment is realised several time, while just a treatment for the selection is needed.
My problem is when I add or remove an element of my tree, the action is very long, according to this treatment, while it should be fast.

Have you an idea to improve this treatment?

Thx,
David.

Report message to a moderator

Re: Problem performance getString of ItemProvider [message #498291 is a reply to message #498276]

Mon, 16 November 2009 11:45

Ed Merks is currently offline

Friend

Messages: 30635
Registered: July 2009

Senior Member

David,

Comments below.

David CHAUTARD wrote:
> Thanks Ed,
>
> Quote:
>> I'd expect it to be proportional to the types of children and the
>> number of selected objects
>
> You think that this behaviour in normal?
It's not entirely clear to me what "this behavior" you're referring to,
but yes, of course it's going to be proportional to the number of menu
entries that need to be populated.
> I understand that these methods are called for the selection, but I
> don't understand why it is done for each element of my tree, because
> the same treatment is realised several time, while just a treatment
> for the selection is needed.
I don't understand either and that's not normal behavior. I imagine the
debugger would be better at explaining this than me.
> My problem is when I add or remove an element of my tree, the action
> is very long, according to this treatment, while it should be fast.
>
> Have you an idea to improve this treatment?
Given that I can't reproduce your problem, it's hard to explain what you
might do differently to avoid it. It seems to me the problem is the
fact it's being called for every element of the tree and not just for
the one selected element.
>
> Thx,
> David.

Report message to a moderator

Re: Problem performance getString of ItemProvider [message #498331 is a reply to message #498291]

Mon, 16 November 2009 14:03

David CHAUTARD is currently offline

Friend

Messages: 102
Registered: July 2009

Senior Member

Ed,

Quote:

> I understand that these methods are called for the selection, but I
> don't understand why it is done for each element of my tree, because
> the same treatment is realised several time, while just a treatment
> for the selection is needed.
I don't understand either and that's not normal behavior. I imagine the
debugger would be better at explaining this than me.

In fact, these methods are called each time I select an element in the tree, for its label in the tree. But also for the Child/Sibling labels for the contextual menu on the selected element (ItemProvider). And the number of calls are always the same for the selection. And the problem is that it is often for the same labels.

David.

Report message to a moderator

Re: Problem performance getString of ItemProvider [message #498569 is a reply to message #498331]

Tue, 17 November 2009 14:32

Ed Merks is currently offline

Friend

Messages: 30635
Registered: July 2009

Senior Member

David,

So you're confirming what I said. Do you have an usually large number
of possible children? Even in UML where there are often hundreds of
choices I don't see any significant pauses when bringing up a pop-up
menu... I suppose you might try caching the values in a map, but
property lookup already does such caching...

David CHAUTARD wrote:
> Ed,
>
> Quote:
>> > I understand that these methods are called for the selection, but I
>> > don't understand why it is done for each element of my tree, because
>> > the same treatment is realised several time, while just a treatment
>> > for the selection is needed.
>> I don't understand either and that's not normal behavior. I imagine the
>> debugger would be better at explaining this than me.
>
>
> In fact, these methods are called each time I select an element in the
> tree, for its label in the tree. But also for the Child/Sibling labels
> for the contextual menu on the selected element (ItemProvider). And
> the number of calls are always the same for the selection. And the
> problem is that it is often for the same labels.
>
> David.
>

Report message to a moderator

Re: Problem performance getString of ItemProvider [message #499177 is a reply to message #498569]

Fri, 20 November 2009 10:07

David CHAUTARD is currently offline

Friend

Messages: 102
Registered: July 2009

Senior Member

Hy,
I use the debugger to test if the problem comes form the refresh of my tree (ContentProvider). I comment the refresh action, and when I add a new element in my tree (new Sibling), the application is always stick during some seconds. I think the problem should be in the add command, when there is a lot of element in the tree, but I can see where this action is called, just when it is created.

Do you know where I can see that?
Thx,
David.

Report message to a moderator

Re: Problem performance getString of ItemProvider [message #499242 is a reply to message #499177]

Fri, 20 November 2009 14:20

Ed Merks is currently offline

Friend

Messages: 30635
Registered: July 2009

Senior Member

David,

An AddCommand has an execute method where all the activity takes place.

David CHAUTARD wrote:
> Hy,
> I use the debugger to test if the problem comes form the refresh of my
> tree (ContentProvider). I comment the refresh action, and when I add a
> new element in my tree (new Sibling), the application is always stick
> during some seconds. I think the problem should be in the add command,
> when there is a lot of element in the tree, but I can see where this
> action is called, just when it is created.
>
> Do you know where I can see that?
> Thx,
> David.

Report message to a moderator

Re: Problem performance getString of ItemProvider [message #499523 is a reply to message #499242]

Mon, 23 November 2009 08:26

David CHAUTARD is currently offline

Friend

Messages: 102
Registered: July 2009

Senior Member

Hi Ed,

you are all right. I debbug the AddCommand action, and I think I find where my application stick. It is in the doExecute() method at the line :

ownerList.addAll(index, collection);

I think this action take a lot of time as ownerList contains 15000 elements.

Do you know how can I improve this method behaviour?
Thx,
David.

Report message to a moderator

Re: Problem performance getString of ItemProvider [message #499569 is a reply to message #499523]

Mon, 23 November 2009 11:38

Ed Merks is currently offline

Friend

Messages: 30635
Registered: July 2009

Senior Member

David,

Likely it's the code responding to the notification that's taking most
of the time, rather than the actual update. Keep in mind that if I know
obvious ways to improve the performance of something, it would have been
done long ago...

David CHAUTARD wrote:
> Hi Ed,
>
> you are all right. I debbug the AddCommand action, and I think I find
> where my application stick. It is in the doExecute() method at the line :
> ownerList.addAll(index, collection);
>
> I think this action take a lot of time as ownerList contains 15000
> elements.
>
> Do you know how can I improve this method behaviour?
> Thx,
> David.

Report message to a moderator

Re: Problem performance getString of ItemProvider [message #499589 is a reply to message #499569]

Mon, 23 November 2009 12:38

David CHAUTARD is currently offline

Friend

Messages: 102
Registered: July 2009

Senior Member

Thanks you a lot Ed for your help.

I test the action to add an elment without refreshing if my tree, and the application is always stick. And when I debbug step by step, we can see we spend lots of time in this method.

Quote:

Keep in mind that if I know obvious ways to improve the performance of something, it would have been done long ago...

What I meant is if I could improve something in my code, in order to manage the command creation or something else. But I think having so much elements in my tree is very effective.

Thx,
David.

Report message to a moderator

Re: Problem performance getString of ItemProvider [message #499607 is a reply to message #499589]

Mon, 23 November 2009 14:29

Ed Merks is currently offline

Friend

Messages: 30635
Registered: July 2009

Senior Member

David,

In my experience, the only way to performance tune is to have accurate
measurements that help highlight the bottlenecks so you can focus your
attention on the places that will have the most impact. Without such
measurements, it's more of a guesswork activity...

David CHAUTARD wrote:
> Thanks you a lot Ed for your help.
>
> I test the action to add an elment without refreshing if my tree, and
> the application is always stick. And when I debbug step by step, we
> can see we spend lots of time in this method.
>
> Quote:
>> Keep in mind that if I know obvious ways to improve the performance
>> of something, it would have been done long ago...
>
> What I meant is if I could improve something in my code, in order to
> manage the command creation or something else. But I think having so
> much elements in my tree is very effective.
>
> Thx,
> David.

Report message to a moderator

Re: Problem performance getString of ItemProvider [message #499982 is a reply to message #499607]

Tue, 24 November 2009 16:15

David CHAUTARD is currently offline

Friend

Messages: 102
Registered: July 2009

Senior Member

Hi,
I totally agree with you. But in some case we can have a size limitation for an action. And I don't know what is this limitation for an ArrayList. I search a way to improve my action in order not to stick my application. I think about synchronisation, but I don't know how to etablish it without modify embedded code.

In all case thanks for your help,
David.

Report message to a moderator

Switch to threaded view of this topic

Create a new topic

Submit Reply

Previous Topic:	[EMF Compare] rightParent reference in DiffGroups
Next Topic:	how can i access/get into my ###Imp Objects

Goto Forum:

-=] Back to Top [=-

[ Syndicate this forum (XML) ] [

]

Current Time: Fri Nov 15 15:20:00 GMT 2019

Powered by FUDForum. Page generated in 0.02896 seconds

.:: Contact :: Home ::.

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

Back to the top