Package load times
Locked
 
|
I've recently upgraded a project to Pharo 2 which went relatively
smoothly but thought I'd share my experience with loading times In Pharo 1.4, it used to take about 5-6 minutes to build everything from a base image but I noticed that if I ran the package loads inside a SystemChangeNotifier uniqueInstance doSilently: then the load time went down to like 2 minutes without any other side effects. In Pharo 2, it was taking a lot longer so I ran it through the equivalent SystemAnnouncer uniqueInstance suspendAllWhile: which did the job in terms of speed but all of the classes ended up unpackaged. After a little bit of digging I eventually found that by running MCWorkingCopy unregisterForNotifications before the package load, it came back to a sensible load time and everything seems to work again. My question is can this practice become part of a configuration load? I tried loading Iliad from the package cache just as an example and if you do a ConfigurationOfIliad load it takes 310 seconds, whereas MCWorkingCopy unregisterForNotifications. ConfigurationOfIliad load. MCWorkingCopy registerForNotifications. only takes 42 seconds. The main problem seems to be MCPackageManager>>#methodModified which sets the package modified state is taking about 60m/s to run each time because it is initializing an RPackage for every package in the system. Is there any way this can be cached better? Cheers Chris |
Re: Package load times
|
|
Hi Chris,
On 20 Apr 2013, at 22:56, Chris <[hidden email]> wrote: > I've recently upgraded a project to Pharo 2 which went relatively smoothly but thought I'd share my experience with loading times > > In Pharo 1.4, it used to take about 5-6 minutes to build everything from a base image but I noticed that if I ran the package loads inside a SystemChangeNotifier uniqueInstance doSilently: then the load time went down to like 2 minutes without any other side effects. > > In Pharo 2, it was taking a lot longer so I ran it through the equivalent SystemAnnouncer uniqueInstance suspendAllWhile: which did the job in terms of speed but all of the classes ended up unpackaged. After a little bit of digging I eventually found that by running MCWorkingCopy unregisterForNotifications before the package load, it came back to a sensible load time and everything seems to work again. > > My question is can this practice become part of a configuration load? I tried loading Iliad from the package cache just as an example and if you do a ConfigurationOfIliad load it takes 310 seconds, whereas MCWorkingCopy unregisterForNotifications. ConfigurationOfIliad load. MCWorkingCopy registerForNotifications. only takes 42 seconds. The main problem seems to be MCPackageManager>>#methodModified which sets the package modified state is taking about 60m/s to run each time because it is initializing an RPackage for every package in the system. Is there any way this can be cached better? > > Cheers > Chris I can't answer myself, but I support your question. Loading takes way too long, your solution seems to go in the right direction, now it is up to the experts... Sven -- Sven Van Caekenberghe Proudly supporting Pharo http://pharo.org http://association.pharo.org http://consortium.pharo.org |
|
|
In reply to this post by xx397
Thanks for investigating that. We will have to have a look.
We have a sprint in two weeks and I will sit with esteban if he wants to have a look. Stef On Apr 20, 2013, at 10:56 PM, Chris <[hidden email]> wrote: > I've recently upgraded a project to Pharo 2 which went relatively smoothly but thought I'd share my experience with loading times > > In Pharo 1.4, it used to take about 5-6 minutes to build everything from a base image but I noticed that if I ran the package loads inside a SystemChangeNotifier uniqueInstance doSilently: then the load time went down to like 2 minutes without any other side effects. > > In Pharo 2, it was taking a lot longer so I ran it through the equivalent SystemAnnouncer uniqueInstance suspendAllWhile: which did the job in terms of speed but all of the classes ended up unpackaged. After a little bit of digging I eventually found that by running MCWorkingCopy unregisterForNotifications before the package load, it came back to a sensible load time and everything seems to work again. > > My question is can this practice become part of a configuration load? I tried loading Iliad from the package cache just as an example and if you do a ConfigurationOfIliad load it takes 310 seconds, whereas MCWorkingCopy unregisterForNotifications. ConfigurationOfIliad load. MCWorkingCopy registerForNotifications. only takes 42 seconds. The main problem seems to be MCPackageManager>>#methodModified which sets the package modified state is taking about 60m/s to run each time because it is initializing an RPackage for every package in the system. Is there any way this can be cached better? > > Cheers > Chris > > |
|
|
In reply to this post by xx397
On 20 April 2013 22:56, Chris <[hidden email]> wrote:
> I've recently upgraded a project to Pharo 2 which went relatively smoothly > but thought I'd share my experience with loading times > > In Pharo 1.4, it used to take about 5-6 minutes to build everything from a > base image but I noticed that if I ran the package loads inside a > SystemChangeNotifier uniqueInstance doSilently: then the load time went down > to like 2 minutes without any other side effects. > > In Pharo 2, it was taking a lot longer so I ran it through the equivalent > SystemAnnouncer uniqueInstance suspendAllWhile: which did the job in terms > of speed but all of the classes ended up unpackaged. After a little bit of > digging I eventually found that by running MCWorkingCopy > unregisterForNotifications before the package load, it came back to a > sensible load time and everything seems to work again. SystemAnnouncer suspension is buggy. announce: anAnnouncement self isSuspended ifFalse: [ self private announce: anAnnouncement. super announce: anAnnouncement ] should be: announce: anAnnouncement self private announce: anAnnouncement. self isSuspended ifFalse: [ super announce: anAnnouncement ] > > My question is can this practice become part of a configuration load? I > tried loading Iliad from the package cache just as an example and if you do > a ConfigurationOfIliad load it takes 310 seconds, whereas MCWorkingCopy > unregisterForNotifications. ConfigurationOfIliad load. MCWorkingCopy > registerForNotifications. only takes 42 seconds. The main problem seems to > be MCPackageManager>>#methodModified which sets the package modified state > is taking about 60m/s to run each time because it is initializing an > RPackage for every package in the system. Is there any way this can be > cached better? > > Cheers > Chris > > -- Best regards, Igor Stasenko. |
|
|
igor can you open a bug entry so that we do not forget it.
tx Stef On Apr 21, 2013, at 5:49 PM, Igor Stasenko <[hidden email]> wrote: > On 20 April 2013 22:56, Chris <[hidden email]> wrote: >> I've recently upgraded a project to Pharo 2 which went relatively smoothly >> but thought I'd share my experience with loading times >> >> In Pharo 1.4, it used to take about 5-6 minutes to build everything from a >> base image but I noticed that if I ran the package loads inside a >> SystemChangeNotifier uniqueInstance doSilently: then the load time went down >> to like 2 minutes without any other side effects. >> >> In Pharo 2, it was taking a lot longer so I ran it through the equivalent >> SystemAnnouncer uniqueInstance suspendAllWhile: which did the job in terms >> of speed but all of the classes ended up unpackaged. After a little bit of >> digging I eventually found that by running MCWorkingCopy >> unregisterForNotifications before the package load, it came back to a >> sensible load time and everything seems to work again. > > SystemAnnouncer suspension is buggy. > > announce: anAnnouncement > self isSuspended > ifFalse: [ > self private announce: anAnnouncement. > super announce: anAnnouncement ] > should be: > > announce: anAnnouncement > self private announce: anAnnouncement. > self isSuspended > ifFalse: [ > super announce: anAnnouncement ] > > >> >> My question is can this practice become part of a configuration load? I >> tried loading Iliad from the package cache just as an example and if you do >> a ConfigurationOfIliad load it takes 310 seconds, whereas MCWorkingCopy >> unregisterForNotifications. ConfigurationOfIliad load. MCWorkingCopy >> registerForNotifications. only takes 42 seconds. The main problem seems to >> be MCPackageManager>>#methodModified which sets the package modified state >> is taking about 60m/s to run each time because it is initializing an >> RPackage for every package in the system. Is there any way this can be >> cached better? >> > yes the code there needs review. > >> Cheers >> Chris >> >> > > > > -- > Best regards, > Igor Stasenko. > |
|
|
I have been noticing this slowdown too. Sorry I don't have much to say, but it is way slower than in 1.4. You are not alone!
On Sun, Apr 21, 2013 at 4:30 PM, stephane ducasse <[hidden email]> wrote: igor can you open a bug entry so that we do not forget it. Mariano http://marianopeck.wordpress.com |
|
Administrator
|
In reply to this post by xx397
|
«
Return to Pharo Smalltalk Users
|
1 view|%1 views
| Free forum by Nabble | Edit this page |