Home » Eclipse Projects » GEF » Large diagram with a large number of EditParts
| Large diagram with a large number of EditParts [message #121042] |
Mon, 08 March 2004 13:57  |
Eclipse User |
|
|
|
Originally posted by: brian.fernandes.codito.com
Hi Guys,
I have a very large diagram *sigh*; 200 million pixels wide.
This diagram has several rows in a toolbar layout (vertical) and each row
has it's contents in an XYLayout.
The contents are just RectangleFigures. It's actually a gantt chart with
each bar of the chart being displayed by a rectangle.
the problem is that I currently have about 80,000 EditParts (4 rows - 20K /
row) - and this number will increase - maybe triple or so.
I run my vm with -Xmx500m and -Xms300m . The files contents are parsed in
negligible time - but, it takes a long time for the diagram to be visible
and usable. What I use for benchmarking right now is the refresh - I
minimize the workbench and then restore it. It takes about 20 seconds to
refresh. Once refreshed though - it works well.
What I'm worried about here is the startup time and the fact that you can't
really do anything else while using the editor - or you wait for 20 seconds
before it's usuable again. Other operations like changing the color of a bar
/ or it's visibility take a similar amount of time (though I haven't really
given those operations too much thought and I'm probably doing extra work
here)
I have a 2.4Ghz P4 with 512 mb ram - running Eclipse 3m7 with a pretty
recent CVS checkout of GEF on W2K.
The individual figures are simple rectangles as I mentioned earlier - their
refresh visuals looks something like this..
protected void refreshVisuals() {
Rectangle rect = model.getConstraint();
((GraphicalEditPart)
getParent()).setLayoutConstraint(this,getFigure(),rect);
}
The refreshVisuals for the rows in the toolbar layout are standard - if
refreshVisuals and refreshChildren() when appropriate.
I don't want to go down to D2d, because I already am using the context
menus, property sheets, and other views.
Anything I can do to increase the efficiency - or anything I could be doing
wrong ?
I'm really stumped at this point, any suggestions appreciated ....
Thanks,
Brian.
|
|
|
| Re: Large diagram with a large number of EditParts [message #121051 is a reply to message #121042] |
Mon, 08 March 2004 20:01  |
| Eclipse User |
|
|
|
Are the four rows four different edit parts? If not, dividing the 80,000
editparts into children of 4 editparts will help a little. The more
branches in your figure tree hierarchy, the better. This'll lead to better
performance when, for instance, doing List.contains() checks, as it'll have
to look among 20,000 items, not 80,000.
When we did some testing, we realized that when a figure has a lot of
children, methods like contains(), remove(), etc. -- methods which have to
iterate over the list -- consume a lot of time. So, you might want to
minimize instances of these wherever possible. You can also change the GEF
code (for eg., you could change Figure.remove(IFigure) so that it doesn't do
a contains check before removing the Figure). Another optimization would be
to use a list backed up by a HashSet or HashMap or something like that,
instead of an ArrayList. When you have such a large number of children,
ArrayList is not very effective. Needless to say, such optimizations can
also help out in your model and EditPart hierarchies. However, keep in mind
that modifying the GEF code has license implications.
Do some profiling and see if you can identify any more problem areas. We'd
be interested to know if you find any. BTW, what is the workbench's memory
usage when you have this file up?
"Brian Fernandes" <brian.fernandes@codito.com> wrote in message
news:c2ifda$5o8$1@eclipse.org...
> Hi Guys,
>
> I have a very large diagram *sigh*; 200 million pixels wide.
> This diagram has several rows in a toolbar layout (vertical) and each row
> has it's contents in an XYLayout.
> The contents are just RectangleFigures. It's actually a gantt chart with
> each bar of the chart being displayed by a rectangle.
>
> the problem is that I currently have about 80,000 EditParts (4 rows - 20K
/
> row) - and this number will increase - maybe triple or so.
>
> I run my vm with -Xmx500m and -Xms300m . The files contents are parsed in
> negligible time - but, it takes a long time for the diagram to be visible
> and usable. What I use for benchmarking right now is the refresh - I
> minimize the workbench and then restore it. It takes about 20 seconds to
> refresh. Once refreshed though - it works well.
> What I'm worried about here is the startup time and the fact that you
can't
> really do anything else while using the editor - or you wait for 20
seconds
> before it's usuable again. Other operations like changing the color of a
bar
> / or it's visibility take a similar amount of time (though I haven't
really
> given those operations too much thought and I'm probably doing extra work
> here)
>
> I have a 2.4Ghz P4 with 512 mb ram - running Eclipse 3m7 with a pretty
> recent CVS checkout of GEF on W2K.
>
> The individual figures are simple rectangles as I mentioned earlier -
their
> refresh visuals looks something like this..
>
> protected void refreshVisuals() {
> Rectangle rect = model.getConstraint();
> ((GraphicalEditPart)
> getParent()).setLayoutConstraint(this,getFigure(),rect);
> }
>
>
> The refreshVisuals for the rows in the toolbar layout are standard - if
> refreshVisuals and refreshChildren() when appropriate.
>
> I don't want to go down to D2d, because I already am using the context
> menus, property sheets, and other views.
>
> Anything I can do to increase the efficiency - or anything I could be
doing
> wrong ?
>
> I'm really stumped at this point, any suggestions appreciated ....
>
> Thanks,
> Brian.
>
>
|
|
|
| Re: Large diagram with a large number of EditParts [message #121067 is a reply to message #121051] |
Tue, 09 March 2004 04:52 |
| Eclipse User |
|
|
|
Originally posted by: brian.fernandes.codito.com
Hi Pratik,
"Pratik Shah" <ppshah@us.ibm.com> wrote in message
news:c2j4qn$es$1@eclipse.org...
> Are the four rows four different edit parts? If not, dividing the 80,000
> editparts into children of 4 editparts will help a little. The more
> branches in your figure tree hierarchy, the better. This'll lead to
better
> performance when, for instance, doing List.contains() checks, as it'll
have
> to look among 20,000 items, not 80,000.
>
This is what I'm doing already. The four rows are in a toolbar layout and
each of them have about 20K children.
If I divide each of my rows into columns, and distribute the 20K editparts
among those columns - do you think it will be more efficient ? I can
understand how this might work - so, if I divide into a large enough number
of columns (I guess I'll have to play with this number), do you think I'll
get a substantial improvement ?
> When we did some testing, we realized that when a figure has a lot of
> children, methods like contains(), remove(), etc. -- methods which have to
> iterate over the list -- consume a lot of time. So, you might want to
> minimize instances of these wherever possible. You can also change the
GEF
> code (for eg., you could change Figure.remove(IFigure) so that it doesn't
do
> a contains check before removing the Figure)
My editor is read only. All you can do is select elements (to see their
properties in the PropertyView) and there is a draw2d tooltip display on
mouseover. You can clip the diagram (as discussed in an earlier post -
"Clipping Diagrams") but that does not concern me right now - what bothers
me is the 20 second refresh - so if you ALT-TAB you have to wait for 20s
before you can use the editor again. So - with the current usage of the
editor, do contains() and remove() come into play ?
I've understood your points though - and iteration will indeed be slow for
20K children..
Another optimization would be
> to use a list backed up by a HashSet or HashMap or something like that,
> instead of an ArrayList. When you have such a large number of children,
> ArrayList is not very effective. Needless to say, such optimizations can
> also help out in your model and EditPart hierarchies. However, keep in
mind
> that modifying the GEF code has license implications.
>
Good idea. Understood.
I'm unaware right now about what happens when the diagram is refreshed - a
workbench minimize and maximize. Do you go through all the editParts, redraw
them or what ? I'm sure the diagram is clipped - in which case, I can't see
why a refresh takes so long if only about 1000 pixels of the diagram are
visible.
Could you point me to the methods responsible for this ? I have some
experience with BSP trees, octrees, 3d engines etc. I know we won't need to
go there, but perhaps something could be done about this - will contribute
back to GEF of course if it does make a difference to the rendering
efficiency.
> Do some profiling and see if you can identify any more problem areas.
I'm unsure of what you mean here. How do you suggest I profile the editor ?
Instrument GEF code ?
>We'd be interested to know if you find any. BTW, what is the workbench's
memory
> usage when you have this file up?
About 180 MB. BTW - I've tried this editor out on a similar machine with
only 256MB ram, as against the 512MB which I have. There was virtually no
difference in the speed.
There are a large number of page faults initially but once loaded - it does
not page fault much. I'm also working with scaled down diagrams - my final
diagrams will have 12 rows and each row might contain about 40K editparts
(though some rows are not as populated as others).
Your thoughts ?
Thanks,
Brian.
|
|
| | | | | | | | | |
| Re: Large diagram with a large number of EditParts [message #121740 is a reply to message #121691] |
Wed, 10 March 2004 18:35 |
| Eclipse User |
|
|
|
Originally posted by: brian.fernandes.codito.com
"Randy Hudson" <none@us.ibm.com> wrote in message
news:c2nn3g$in5$1@eclipse.org...
> Why do you need figures to be focus traversable? Maybe you can get rid of
> the focusTraverse guy and replace it with one that does nothing. Focus
> traversal is rarely used in figure. An example of usage is the GEF
palette.
>
When I restore the workbench - SWTEventDispatcher#dispatchFocusGained()
first checks the current focus owner - since nothing is found it "tries to
focus on the first focusable child"
For some reason it tries to find a focusable child within my viewport.
Perhaps this is because my editor does not have a palette - if it did , it
would probably have had a current focus owner, failing which the search
would have stopped within the palette itself... ? I don't know wheter focus
on a particular figure in the Viewport is ever going to be required - if not
, perhaps the search within the viewport should be disabled. It probably
goes unnoticed in most editors, but in my case, with 80K EditParts (none of
which were Focus Traversable), it certainly took a large amount of time.
> Also, if you have specific methods which are slow maybe there is an easy
fix
> you can suggest?
>
None at this point - making my row figures (there will be just 4-12 of them)
focus traversable (and thus stopping the search early) has brought down the
wait time from 20 seconds to zip. Operations like changing visibility, color
etc. are almost instantaneous even with 80K EditParts.
At a later point, I might actually be doing some editing in the editor -
right now it's display only; perhaps then I will experience some slow down -
will report the findings back here then. I will also be working with larger
diagrams shortly ... but right now, I'm impressed with the performance I'm
getting out of GEF.
Thanks,
Brian.
|
|
|
Goto Forum:
Current Time: Thu Jul 17 19:52:53 EDT 2025
Powered by FUDForum. Page generated in 0.09069 seconds |
Home