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
Hi Chris, On 20 Apr 2013, at 22:56, Chris <cpmbailey@btinternet.com> 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
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 <cpmbailey@btinternet.com> 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
On 20 April 2013 22:56, Chris <cpmbailey@btinternet.com> 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.
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 <siguctua@gmail.com> wrote:
On 20 April 2013 22:56, Chris <cpmbailey@btinternet.com> 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 <stephane.ducasse@free.fr>wrote:
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 <siguctua@gmail.com> wrote:
On 20 April 2013 22:56, Chris <cpmbailey@btinternet.com> 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.
-- Mariano http://marianopeck.wordpress.com
I created https://pharo.fogbugz.com/f/cases/10368/Slow-Monticello-loading ----- Cheers, Sean -- View this message in context: http://forum.world.st/Package-load-times-tp4682793p4683024.html Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.
participants (6)
-
Chris -
Igor Stasenko -
Mariano Martinez Peck -
Sean P. DeNigris -
stephane ducasse -
Sven Van Caekenberghe