Roassal Performance Issues when applying layout
Locked
Roassal Performance Issues when applying layout
 
|
Hello, we are Pablo Polanco and Jorge Ampuero and we are Computer Science students at Universidad de Chile. We are currently taking a course on Robotics Software Engineering dictated by Johan Fabry.We provide the report from the Time Profiler when we visualize 13 elements and 38 edges: http://pastebin.com/zsh8YFPx Should it take so much time? How could we improve it? Is there another more appropriate layout? Thanks in advance :)  |
Re: Roassal Performance Issues when applying layout
|
|
Hi,
It is really difficult to help you just with a profile and without looking at your code. Even though, I have noticed that most of the time is used on calculating properties related to CompositeShapes (like position and encompassing rectangle). Would be possible for you to run the same code but replacing the CompositeShape by another less complex shape (like RTBox)? If this new experiment is fast, then the problem would be those 2 properties (position and encompassing rectangle) are too expensive, and therefore we should think how to optimize that code. I know that ForceLayout is not the fastest layout, but 59 seconds is too much for just 13 elements. Cheers, Alejandro
|
Re: Roassal Performance Issues when applying layout
|
|
On 12/07, Alejandro Infante wrote:
> Hi, > It is really difficult to help you just with a profile and without looking at your code. > Even though, I have noticed that most of the time is used on calculating properties related to CompositeShapes (like position and encompassing rectangle). > > Would be possible for you to run the same code but replacing the CompositeShape by another less complex shape (like RTBox)? > If this new experiment is fast, then the problem would be those 2 properties (position and encompassing rectangle) are too expensive, and therefore we should think how to optimize that code. > > I know that ForceLayout is not the fastest layout, but 59 seconds is too much for just 13 elements. The complexity should be nlog(n) per iteration. For such small diagram this should be pretty much instant. However from the profiler I can see that a _lot_ of time is spent in calculating the label size, which definitely shouldn't be this slow... If you want to look at the other layouts, look at this https://dl.dropboxusercontent.com/u/31543901/AgileVisualization/Layout/0106-Layout.html > > Cheers, > Alejandro > > > On Dec 7, 2015, at 5:26 PM, Pablo Polanco <[hidden email]> wrote: > > > > Hello, we are Pablo Polanco and Jorge Ampuero and we are Computer Science students at Universidad de Chile. > > > > We are currently taking a course on Robotics Software Engineering dictated by Johan Fabry. > > > > We want to visualize a simple directed graph and we are experiencing performance issues when layouting our visualization in Roassal. > > > > We provide the report from the Time Profiler when we visualize 13 elements and 38 edges: http://pastebin.com/zsh8YFPx <http://pastebin.com/zsh8YFPx> > > > > Should it take so much time? How could we improve it? Is there another more appropriate layout? > > > > Thanks in advance :) > > > > <Screenshot from 2015-12-07 17:23:05.png> > > > -- Peter |
|
|
In reply to this post by Pablo Polanco
Hi Pablo,
This is great that you contact the mailing list. You have apparently found a bug in the way composite shapes are implemented. I have fixed the problem by introducing a new class RTOptimizedForceBaseLayout. Please, update Roassal and try it. It should be super fast. Else, feel free to come to my office this Wednesday at 9:00 am :-) Cheers, Alexandre > On Dec 7, 2015, at 5:26 PM, Pablo Polanco <[hidden email]> wrote: > > Hello, we are Pablo Polanco and Jorge Ampuero and we are Computer Science students at Universidad de Chile. > > We are currently taking a course on Robotics Software Engineering dictated by Johan Fabry. > > We want to visualize a simple directed graph and we are experiencing performance issues when layouting our visualization in Roassal. > > We provide the report from the Time Profiler when we visualize 13 elements and 38 edges: http://pastebin.com/zsh8YFPx > > Should it take so much time? How could we improve it? Is there another more appropriate layout? > > Thanks in advance :) > > <Screenshot from 2015-12-07 17:23:05.png> > -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. |
|
|
In reply to this post by Peter Uhnak
On Tue, Dec 8, 2015 at 6:17 AM, Peter Uhnak <[hidden email]> wrote:
> On 12/07, Alejandro Infante wrote: >> Hi, >> It is really difficult to help you just with a profile and without looking at your code. >> Even though, I have noticed that most of the time is used on calculating properties related to CompositeShapes (like position and encompassing rectangle). >> >> Would be possible for you to run the same code but replacing the CompositeShape by another less complex shape (like RTBox)? >> If this new experiment is fast, then the problem would be those 2 properties (position and encompassing rectangle) are too expensive, and therefore we should think how to optimize that code. >> >> I know that ForceLayout is not the fastest layout, but 59 seconds is too much for just 13 elements. > > The complexity should be nlog(n) per iteration. > For such small diagram this should be pretty much instant. > > However from the profiler I can see that a _lot_ of time is spent in > calculating the label size, which definitely shouldn't be this slow... I had this problem with labels a while a go in Rossal 1 when using Unicode in a label. https://github.com/moosetechnology/moose/issues/898 From memory it came down to calculating the width of a unicode string. I think I hacked it in the rendering loop, such that the string width is cached along with a copy of the string. Next iteration if the string was the same return the cached value, otherwise recalculate. I think I discounted resetting the cache to nil when setting the label string due to inter thread races. cheers -ben > > If you want to look at the other layouts, look at this > https://dl.dropboxusercontent.com/u/31543901/AgileVisualization/Layout/0106-Layout.html > >> >> Cheers, >> Alejandro >> >> > On Dec 7, 2015, at 5:26 PM, Pablo Polanco <[hidden email]> wrote: >> > >> > Hello, we are Pablo Polanco and Jorge Ampuero and we are Computer Science students at Universidad de Chile. >> > >> > We are currently taking a course on Robotics Software Engineering dictated by Johan Fabry. >> > >> > We want to visualize a simple directed graph and we are experiencing performance issues when layouting our visualization in Roassal. >> > >> > We provide the report from the Time Profiler when we visualize 13 elements and 38 edges: http://pastebin.com/zsh8YFPx <http://pastebin.com/zsh8YFPx> >> > >> > Should it take so much time? How could we improve it? Is there another more appropriate layout? >> > >> > Thanks in advance :) >> > >> > <Screenshot from 2015-12-07 17:23:05.png> >> > >> > > -- > Peter > |
|
|
On Tue, Dec 8, 2015 at 10:19 PM, Ben Coman <[hidden email]> wrote:
> On Tue, Dec 8, 2015 at 6:17 AM, Peter Uhnak <[hidden email]> wrote: >> On 12/07, Alejandro Infante wrote: >>> Hi, >>> It is really difficult to help you just with a profile and without looking at your code. >>> Even though, I have noticed that most of the time is used on calculating properties related to CompositeShapes (like position and encompassing rectangle). >>> >>> Would be possible for you to run the same code but replacing the CompositeShape by another less complex shape (like RTBox)? >>> If this new experiment is fast, then the problem would be those 2 properties (position and encompassing rectangle) are too expensive, and therefore we should think how to optimize that code. >>> >>> I know that ForceLayout is not the fastest layout, but 59 seconds is too much for just 13 elements. >> >> The complexity should be nlog(n) per iteration. >> For such small diagram this should be pretty much instant. >> >> However from the profiler I can see that a _lot_ of time is spent in >> calculating the label size, which definitely shouldn't be this slow... > > I had this problem with labels a while a go in Rossal 1 when using > Unicode in a label. > https://github.com/moosetechnology/moose/issues/898 > > From memory it came down to calculating the width of a unicode string. > I think I hacked it in the rendering loop, such that the string width > is cached along with a copy of the string. Next iteration if the > string was the same return the cached value, otherwise recalculate. I > think I discounted resetting the cache to nil when setting the label > string due to inter thread races. > > cheers -ben Spur should help also with WideString ~8 times speedup https://www.mail-archive.com/pharo-dev@.../msg12397.html which we should be able to test soon... cheers -ben > >> >> If you want to look at the other layouts, look at this >> https://dl.dropboxusercontent.com/u/31543901/AgileVisualization/Layout/0106-Layout.html >> >>> >>> Cheers, >>> Alejandro >>> >>> > On Dec 7, 2015, at 5:26 PM, Pablo Polanco <[hidden email]> wrote: >>> > >>> > Hello, we are Pablo Polanco and Jorge Ampuero and we are Computer Science students at Universidad de Chile. >>> > >>> > We are currently taking a course on Robotics Software Engineering dictated by Johan Fabry. >>> > >>> > We want to visualize a simple directed graph and we are experiencing performance issues when layouting our visualization in Roassal. >>> > >>> > We provide the report from the Time Profiler when we visualize 13 elements and 38 edges: http://pastebin.com/zsh8YFPx <http://pastebin.com/zsh8YFPx> >>> > >>> > Should it take so much time? How could we improve it? Is there another more appropriate layout? >>> > >>> > Thanks in advance :) >>> > >>> > <Screenshot from 2015-12-07 17:23:05.png> >>> > >>> >> >> -- >> Peter >> |
|
|
Currently text in Roassal does not work with Spur: it is wrongly positioned, and does not appear sometime… I did not look into more detail.
Cheers, Alexandre > On Dec 16, 2015, at 2:26 AM, Ben Coman <[hidden email]> wrote: > > On Tue, Dec 8, 2015 at 10:19 PM, Ben Coman <[hidden email]> wrote: >> On Tue, Dec 8, 2015 at 6:17 AM, Peter Uhnak <[hidden email]> wrote: >>> On 12/07, Alejandro Infante wrote: >>>> Hi, >>>> It is really difficult to help you just with a profile and without looking at your code. >>>> Even though, I have noticed that most of the time is used on calculating properties related to CompositeShapes (like position and encompassing rectangle). >>>> >>>> Would be possible for you to run the same code but replacing the CompositeShape by another less complex shape (like RTBox)? >>>> If this new experiment is fast, then the problem would be those 2 properties (position and encompassing rectangle) are too expensive, and therefore we should think how to optimize that code. >>>> >>>> I know that ForceLayout is not the fastest layout, but 59 seconds is too much for just 13 elements. >>> >>> The complexity should be nlog(n) per iteration. >>> For such small diagram this should be pretty much instant. >>> >>> However from the profiler I can see that a _lot_ of time is spent in >>> calculating the label size, which definitely shouldn't be this slow... >> >> I had this problem with labels a while a go in Rossal 1 when using >> Unicode in a label. >> https://github.com/moosetechnology/moose/issues/898 >> >> From memory it came down to calculating the width of a unicode string. >> I think I hacked it in the rendering loop, such that the string width >> is cached along with a copy of the string. Next iteration if the >> string was the same return the cached value, otherwise recalculate. I >> think I discounted resetting the cache to nil when setting the label >> string due to inter thread races. >> >> cheers -ben > > Spur should help also with WideString ~8 times speedup > https://www.mail-archive.com/pharo-dev@.../msg12397.html > > which we should be able to test soon... > cheers -ben > >> >>> >>> If you want to look at the other layouts, look at this >>> https://dl.dropboxusercontent.com/u/31543901/AgileVisualization/Layout/0106-Layout.html >>> >>>> >>>> Cheers, >>>> Alejandro >>>> >>>>> On Dec 7, 2015, at 5:26 PM, Pablo Polanco <[hidden email]> wrote: >>>>> >>>>> Hello, we are Pablo Polanco and Jorge Ampuero and we are Computer Science students at Universidad de Chile. >>>>> >>>>> We are currently taking a course on Robotics Software Engineering dictated by Johan Fabry. >>>>> >>>>> We want to visualize a simple directed graph and we are experiencing performance issues when layouting our visualization in Roassal. >>>>> >>>>> We provide the report from the Time Profiler when we visualize 13 elements and 38 edges: http://pastebin.com/zsh8YFPx <http://pastebin.com/zsh8YFPx> >>>>> >>>>> Should it take so much time? How could we improve it? Is there another more appropriate layout? >>>>> >>>>> Thanks in advance :) >>>>> >>>>> <Screenshot from 2015-12-07 17:23:05.png> >>>>> >>>> >>> >>> -- >>> Peter >>> > -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. |
|
|
that’s most probably a bug in new FFI-NB backend.
I would love some help here :) In any case, I will get back to FFI-NB as soon as I finish migration. Esteban > On 16 Dec 2015, at 12:03, Alexandre Bergel <[hidden email]> wrote: > > Currently text in Roassal does not work with Spur: it is wrongly positioned, and does not appear sometime… I did not look into more detail. > > Cheers, > Alexandre > > >> On Dec 16, 2015, at 2:26 AM, Ben Coman <[hidden email]> wrote: >> >> On Tue, Dec 8, 2015 at 10:19 PM, Ben Coman <[hidden email]> wrote: >>> On Tue, Dec 8, 2015 at 6:17 AM, Peter Uhnak <[hidden email]> wrote: >>>> On 12/07, Alejandro Infante wrote: >>>>> Hi, >>>>> It is really difficult to help you just with a profile and without looking at your code. >>>>> Even though, I have noticed that most of the time is used on calculating properties related to CompositeShapes (like position and encompassing rectangle). >>>>> >>>>> Would be possible for you to run the same code but replacing the CompositeShape by another less complex shape (like RTBox)? >>>>> If this new experiment is fast, then the problem would be those 2 properties (position and encompassing rectangle) are too expensive, and therefore we should think how to optimize that code. >>>>> >>>>> I know that ForceLayout is not the fastest layout, but 59 seconds is too much for just 13 elements. >>>> >>>> The complexity should be nlog(n) per iteration. >>>> For such small diagram this should be pretty much instant. >>>> >>>> However from the profiler I can see that a _lot_ of time is spent in >>>> calculating the label size, which definitely shouldn't be this slow... >>> >>> I had this problem with labels a while a go in Rossal 1 when using >>> Unicode in a label. >>> https://github.com/moosetechnology/moose/issues/898 >>> >>> From memory it came down to calculating the width of a unicode string. >>> I think I hacked it in the rendering loop, such that the string width >>> is cached along with a copy of the string. Next iteration if the >>> string was the same return the cached value, otherwise recalculate. I >>> think I discounted resetting the cache to nil when setting the label >>> string due to inter thread races. >>> >>> cheers -ben >> >> Spur should help also with WideString ~8 times speedup >> https://www.mail-archive.com/pharo-dev@.../msg12397.html >> >> which we should be able to test soon... >> cheers -ben >> >>> >>>> >>>> If you want to look at the other layouts, look at this >>>> https://dl.dropboxusercontent.com/u/31543901/AgileVisualization/Layout/0106-Layout.html >>>> >>>>> >>>>> Cheers, >>>>> Alejandro >>>>> >>>>>> On Dec 7, 2015, at 5:26 PM, Pablo Polanco <[hidden email]> wrote: >>>>>> >>>>>> Hello, we are Pablo Polanco and Jorge Ampuero and we are Computer Science students at Universidad de Chile. >>>>>> >>>>>> We are currently taking a course on Robotics Software Engineering dictated by Johan Fabry. >>>>>> >>>>>> We want to visualize a simple directed graph and we are experiencing performance issues when layouting our visualization in Roassal. >>>>>> >>>>>> We provide the report from the Time Profiler when we visualize 13 elements and 38 edges: http://pastebin.com/zsh8YFPx <http://pastebin.com/zsh8YFPx> >>>>>> >>>>>> Should it take so much time? How could we improve it? Is there another more appropriate layout? >>>>>> >>>>>> Thanks in advance :) >>>>>> >>>>>> <Screenshot from 2015-12-07 17:23:05.png> >>>>>> >>>>> >>>> >>>> -- >>>> Peter >>>> >> > > -- > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > Alexandre Bergel http://www.bergel.eu > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > > > > |
Re: Roassal Performance Issues when applying layout
|
|
2015-12-16 12:10 GMT+01:00 Esteban Lorenzano <[hidden email]>: that’s most probably a bug in new FFI-NB backend. On windows (with spur-vm) most athens examples with transformations and/or text don't work (-> crash the vm). I would love some help here :) where to start? Is there a documentation about ffi/nb changes ( I hope so!). I saw some changes in Athens code but I don't understand it. In any case, I will get back to FFI-NB as soon as I finish migration. Esteban |
|
|
I will do a blog post soon (™) :) cheers, Esteban
|
Re: Roassal Performance Issues when applying layout
|
|
In reply to this post by Nicolai Hess-3-2
2015-12-16 12:28 GMT+01:00 Nicolai Hess <[hidden email]>:
interestingly: AthensSurfaceExamples draw2Strings. -> crash FreeTypeFontProvider current updateFromSystem. AthensSurfaceExamples draw2Strings. -> works
|
«
Return to Pharo Smalltalk Users
|
1 view|%1 views
| Free forum by Nabble | Edit this page |