[Pharo-project] configuration speed
I checked the issue under 3.0 with the configuration loading speed. Main Performance Issues: ------------------------ Gofer: package-cache always used by Gofer => big shared package-cache is very slow RPackageSet: each method/class change trigger the creation of a new RPackageSet for EACH Monticello working copy What was reported is, that disabling the announcements during configuration loading decreases load time. This is due to the RPackageSet problem. No announcements, no new RPackageSets. For a typical configuration loading CommandShell and Soup + 5 packages I got 518'124 new instances of RPackageSet!! Solutions --------- Gofer: removing the package-cache from the default repositories seems like a good thing to me. There are 3 tests failing after that, mostly checking if there is a default repository or not. I would add an explicit statement for the package-cache otherwise. RPackageSet: With a basic cache for RPackageSets I cut the load time to a third! It will need some more love when it comes to changing classes, but for now I invalidate it each time an RPackage changes. issue: https://pharo.fogbugz.com/default.asp?10393
On Apr 24, 2013, at 4:50 PM, Camillo Bruni <camillobruni@gmail.com> wrote:
I checked the issue under 3.0 with the configuration loading speed.
Main Performance Issues: ------------------------ Gofer: package-cache always used by Gofer => big shared package-cache is very slow RPackageSet: each method/class change trigger the creation of a new RPackageSet for EACH Monticello working copy
What was reported is, that disabling the announcements during configuration loading decreases load time. This is due to the RPackageSet problem. No announcements, no new RPackageSets.
For a typical configuration loading CommandShell and Soup + 5 packages I got 518'124 new instances of RPackageSet!!
Just that :) There is something wrong.
Solutions --------- Gofer: removing the package-cache from the default repositories seems like a good thing to me. There are 3 tests failing after that, mostly checking if there is a default repository or not. I would add an explicit statement for the package-cache otherwise.
RPackageSet: With a basic cache for RPackageSets I cut the load time to a third! It will need some more love when it comes to changing classes, but for now I invalidate it each time an RPackage changes.
On 24 April 2013 16:50, Camillo Bruni <camillobruni@gmail.com> wrote:
I checked the issue under 3.0 with the configuration loading speed.
Main Performance Issues: ------------------------ Gofer: package-cache always used by Gofer => big shared package-cache is very slow RPackageSet: each method/class change trigger the creation of a new RPackageSet for EACH Monticello working copy
What was reported is, that disabling the announcements during configuration loading decreases load time. This is due to the RPackageSet problem. No announcements, no new RPackageSets.
For a typical configuration loading CommandShell and Soup + 5 packages I got 518'124 new instances of RPackageSet!!
Solutions --------- Gofer: removing the package-cache from the default repositories seems like a good thing to me. There are 3 tests failing after that, mostly checking if there is a default repository or not. I would add an explicit statement for the package-cache otherwise.
RPackageSet: With a basic cache for RPackageSets I cut the load time to a third! It will need some more love when it comes to changing classes, but for now I invalidate it each time an RPackage changes.
I got one more: - fix model of RPackage to contain same objects as MC package. As a consequence RPackageSets goes to > dev/null
-- Best regards, Igor Stasenko.
On Apr 24, 2013, at 5:27 PM, Igor Stasenko <siguctua@gmail.com> wrote:
On 24 April 2013 16:50, Camillo Bruni <camillobruni@gmail.com> wrote:
I checked the issue under 3.0 with the configuration loading speed.
Main Performance Issues: ------------------------ Gofer: package-cache always used by Gofer => big shared package-cache is very slow RPackageSet: each method/class change trigger the creation of a new RPackageSet for EACH Monticello working copy
What was reported is, that disabling the announcements during configuration loading decreases load time. This is due to the RPackageSet problem. No announcements, no new RPackageSets.
For a typical configuration loading CommandShell and Soup + 5 packages I got 518'124 new instances of RPackageSet!!
Solutions --------- Gofer: removing the package-cache from the default repositories seems like a good thing to me. There are 3 tests failing after that, mostly checking if there is a default repository or not. I would add an explicit statement for the package-cache otherwise.
RPackageSet: With a basic cache for RPackageSets I cut the load time to a third! It will need some more love when it comes to changing classes, but for now I invalidate it each time an RPackage changes.
I got one more: - fix model of RPackage to contain same objects as MC package. As a consequence RPackageSets goes to > dev/null
yeah, you can do it when you want :) Nah, talking serious: that would be probably best choice, but it is an incredible amount of work, that's why we rolled back that last year. It is not that we didn't think on it, or that we didn't try it. it was just not doable in the amount of time we had... for more clarity, remember the "limbo" time last year during esug... we were trying to do it as you say now. Not that we should not doit eventually, but as I said... there are tons of things to adapt in the system... I much would prefer to doit in smaller steps if possible (but I'm not sure that it is possible at all neither, maybe we should sit and do it...). Esteban
-- Best regards, Igor Stasenko.
On 24 April 2013 17:43, Esteban Lorenzano <estebanlm@gmail.com> wrote:
On Apr 24, 2013, at 5:27 PM, Igor Stasenko <siguctua@gmail.com> wrote:
On 24 April 2013 16:50, Camillo Bruni <camillobruni@gmail.com> wrote:
I checked the issue under 3.0 with the configuration loading speed.
Main Performance Issues: ------------------------ Gofer: package-cache always used by Gofer => big shared package-cache is very slow RPackageSet: each method/class change trigger the creation of a new RPackageSet for EACH Monticello working copy
What was reported is, that disabling the announcements during configuration loading decreases load time. This is due to the RPackageSet problem. No announcements, no new RPackageSets.
For a typical configuration loading CommandShell and Soup + 5 packages I got 518'124 new instances of RPackageSet!!
Solutions --------- Gofer: removing the package-cache from the default repositories seems like a good thing to me. There are 3 tests failing after that, mostly checking if there is a default repository or not. I would add an explicit statement for the package-cache otherwise.
RPackageSet: With a basic cache for RPackageSets I cut the load time to a third! It will need some more love when it comes to changing classes, but for now I invalidate it each time an RPackage changes.
I got one more: - fix model of RPackage to contain same objects as MC package. As a consequence RPackageSets goes to > dev/null
yeah, you can do it when you want :)
Nah, talking serious: that would be probably best choice, but it is an incredible amount of work, that's why we rolled back that last year. It is not that we didn't think on it, or that we didn't try it. it was just not doable in the amount of time we had... for more clarity, remember the "limbo" time last year during esug... we were trying to do it as you say now. Not that we should not doit eventually, but as I said... there are tons of things to adapt in the system... I much would prefer to doit in smaller steps if possible (but I'm not sure that it is possible at all neither, maybe we should sit and do it...).
I know and i agree. I just don't feel good that we need patches over patches to make things rolling. Because this is exactly what we were trying to get rid of, when we started with these changes, isn't? I just want to make it clear to people, in what state we are: - RPackage is still on the move but not: - RPackage is done, just need to put few patches (optimizations) here and there. (but yeah, since i don't have a time to work on that, i shut up ;)
Esteban
-- Best regards, Igor Stasenko.
participants (4)
-
Camillo Bruni -
Esteban Lorenzano -
Igor Stasenko -
stephane ducasse