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.
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.
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).
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).
I did the same optimization for the MSE import. Before progress bar took ~25-30% of the export time. Now it is ~3%.
Nice, you set ShouldValidateMetaModel to false manually?
-- Pavel
2017-04-18 15:11 GMT+02:00 Cyril Ferlicot D. cyril.ferlicot@gmail.com:
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).
I did the same optimization for the MSE import. Before progress bar took ~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 Moose-dev@list.inf.unibe.ch 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 Moose-dev@list.inf.unibe.ch https://www.list.inf.unibe.ch/listinfo/moose-dev
Hi,
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.