Hi everyone!
I find the MSE export time far too long in Pharo. I dug up a little in the export algo and found two problems. The first one is easy to improve. The second one less. First problem: FMRepository>>elements. This method transform an IdentitySet to an Array with the #asArray method. This takes ~40% of the export time in a small model (5Mo of Java sources). This #elements method is called by the method #includes: of FMRepository and FMMetaRepository. I propose to change those #includes: methods to use the variable `elements` instead of the getter. It should not change anything since the result of an #includes: on an Array and an IdentitySet should be the same. Second problem: the progress bar Usually a progress bar is used via an iteration on a collection and it update the bar each 200ms. During the export it is not done that way and the bar is managed "manually" because we do not have one iteration. I think it is done far more time than each 200ms and at the end ~15-20% of the export time is spent in the progress bar update. This is far too much. For now, I don't know how to improve this part without changing the actual behavior of the export. If I have time I'll try to improve this part of the export too. Have a good day. -- Cyril Ferlicot https://ferlicot.fr http://www.synectique.eu 2 rue Jacques Prévert 01, 59650 Villeneuve d'ascq France _______________________________________________ Moose-dev mailing list [hidden email] https://www.list.inf.unibe.ch/listinfo/moose-dev signature.asc (817 bytes) Download Attachment |
On 18/04/2017 11:21, Cyril Ferlicot D. wrote:
> Hi everyone! > > I find the MSE export time far too long in Pharo. I dug up a little in > the export algo and found two problems. The first one is easy to > improve. The second one less. > > > First problem: FMRepository>>elements. > > This method transform an IdentitySet to an Array with the #asArray > method. This takes ~40% of the export time in a small model (5Mo of Java > sources). > > This #elements method is called by the method #includes: of FMRepository > and FMMetaRepository. I propose to change those #includes: methods to > use the variable `elements` instead of the getter. It should not change > anything since the result of an #includes: on an Array and an > IdentitySet should be the same. > > > Second problem: the progress bar > > Usually a progress bar is used via an iteration on a collection and it > update the bar each 200ms. During the export it is not done that way and > the bar is managed "manually" because we do not have one iteration. I > think it is done far more time than each 200ms and at the end ~15-20% of > the export time is spent in the progress bar update. This is far too much. > > For now, I don't know how to improve this part without changing the > actual behavior of the export. If I have time I'll try to improve this > part of the export too. > > Have a good day. > I did a quick fix for the progress bar. Now I save the last update time and if it is less than 500ms I do not update the progress bar. Before it took 17% of the parse time in average. Now it takes around 3-4% of the parse time. In total the export time should improve by 50-55% for small models (I did not try on bigger models but it should be around the same). -- Cyril Ferlicot https://ferlicot.fr http://www.synectique.eu 2 rue Jacques Prévert 01, 59650 Villeneuve d'ascq France _______________________________________________ Moose-dev mailing list [hidden email] https://www.list.inf.unibe.ch/listinfo/moose-dev signature.asc (817 bytes) Download Attachment |
On 18/04/2017 11:44, Cyril Ferlicot D. wrote:
> Hi again, > > I did a quick fix for the progress bar. Now I save the last update time > and if it is less than 500ms I do not update the progress bar. Before it > took 17% of the parse time in average. Now it takes around 3-4% of the > parse time. > > In total the export time should improve by 50-55% for small models (I > did not try on bigger models but it should be around the same). > ~25-30% of the export time. Now it is ~3%. -- Cyril Ferlicot https://ferlicot.fr http://www.synectique.eu 2 rue Jacques Prévert 01, 59650 Villeneuve d'ascq France _______________________________________________ Moose-dev mailing list [hidden email] https://www.list.inf.unibe.ch/listinfo/moose-dev signature.asc (817 bytes) Download Attachment |
Nice, you set ShouldValidateMetaModel to false manually? -- Pavel 2017-04-18 15:11 GMT+02:00 Cyril Ferlicot D. <[hidden email]>: On 18/04/2017 11:44, Cyril Ferlicot D. wrote: _______________________________________________ Moose-dev mailing list [hidden email] https://www.list.inf.unibe.ch/listinfo/moose-dev |
On 19/04/2017 11:59, Pavel Krivanek wrote:
> Nice, you set ShouldValidateMetaModel to false manually? > > -- Pavel > > > _______________________________________________ > Moose-dev mailing list > [hidden email] > https://www.list.inf.unibe.ch/listinfo/moose-dev > ShouldValidateMetaModel is a little hack to allow Synectique to use latest Fame because we have some models that are not really correct for Fame. We set it in a initialization of our tools. An example is that FAMIXInvocation link #incomingInvocations to #candidates. This is good for a smalltalk model but not a Java one for example since we do not have a list of candidates but only one destination. So we introduced in our tools an alternative opposite of #incomingInvocations. This is not valid in Fame perspective and we need to disable the check for this model. -- Cyril Ferlicot https://ferlicot.fr http://www.synectique.eu 2 rue Jacques Prévert 01, 59650 Villeneuve d'ascq France _______________________________________________ Moose-dev mailing list [hidden email] https://www.list.inf.unibe.ch/listinfo/moose-dev signature.asc (817 bytes) Download Attachment |
Free forum by Nabble | Edit this page |