Re: [Pharo-dev] [Pharo-users] why is adding instance variables so slow?
Hi, Please letâs move this discussion on pharo-dev. And keep going :) Cheers, Doru
On Apr 14, 2017, at 12:09 PM, Denis Kudriashov <dionisiydk@gmail.com> wrote:
2017-04-14 11:09 GMT+02:00 tesonep@gmail.com <tesonep@gmail.com>: Hi, I think the problem was not clearly explained. This is the scenario that is problematic. This scenario does not happen in the new Spur implementation of forwarding, but I think is happening in the old one.
1. You have, let's say 3 instances of ClassA. 2. You add a new instance variable to ClassA. It produces 2a. A new ClassAv2 is created with the instances variables of ClassA and the newone 2b. 3 Instances of ClassAv2 are created 2c. The values of the instance variables of ClassA are copied to the ones in ClassAv2 (the ones missing are left in nil). 2d. The 3 instances of ClassA are becomed forward to the 3 instances of ClassAv2 2e. The ClassA is becomed forward ClassAv2
I still not see why my example not reflects all these steps. I checked also scenario with class becoming:
c1 := Class1 new. c2 := Class2 new. c1 becomeForward: c2. Class1 becomeForward: Class2. Class2 allInstances "=>#(aClass2)"
It also works in Cog
-- www.tudorgirba.com www.feenk.com "What we can governs what we wish."
Hi, with Yuriy and Miroslava we have tried to finish a pull request for conversion of rules to Renraku. But we had to face to a strange failing tests. It was not clear on the first sight but these tests were failing because of time-outs. Then we realized that the reason for this may be in big amount of records in the ASTCache. After some investigation with Denis we discovered that the real reason is in the presence of garbageCollect call in PharoClassInstaller>>#migrateClasses:to:using: and the big ASTCache only made this call significantly slower. It looks like Denis proved that the removal of this garbageCollect call is safe. So we should try to remove it in Pharo 7 because it evidently makes performance issues. -- Pavel 2017-04-16 8:48 GMT+02:00 Tudor Girba <tudor@tudorgirba.com>:
Hi,
Please letâs move this discussion on pharo-dev. And keep going :)
Cheers, Doru
On Apr 14, 2017, at 12:09 PM, Denis Kudriashov <dionisiydk@gmail.com> wrote:
2017-04-14 11:09 GMT+02:00 tesonep@gmail.com <tesonep@gmail.com>: Hi, I think the problem was not clearly explained. This is the scenario that is problematic. This scenario does not happen in the new Spur implementation of forwarding, but I think is happening in the old one.
1. You have, let's say 3 instances of ClassA. 2. You add a new instance variable to ClassA. It produces 2a. A new ClassAv2 is created with the instances variables of ClassA and the newone 2b. 3 Instances of ClassAv2 are created 2c. The values of the instance variables of ClassA are copied to the ones in ClassAv2 (the ones missing are left in nil). 2d. The 3 instances of ClassA are becomed forward to the 3 instances of ClassAv2 2e. The ClassA is becomed forward ClassAv2
I still not see why my example not reflects all these steps. I checked also scenario with class becoming:
c1 := Class1 new. c2 := Class2 new. c1 becomeForward: c2. Class1 becomeForward: Class2. Class2 allInstances "=>#(aClass2)"
It also works in Cog
-- www.tudorgirba.com www.feenk.com
"What we can governs what we wish."
tx guys On Fri, Nov 17, 2017 at 10:59 AM, Pavel Krivanek <pavel.krivanek@gmail.com> wrote:
Hi,
with Yuriy and Miroslava we have tried to finish a pull request for conversion of rules to Renraku. But we had to face to a strange failing tests. It was not clear on the first sight but these tests were failing because of time-outs. Then we realized that the reason for this may be in big amount of records in the ASTCache. After some investigation with Denis we discovered that the real reason is in the presence of garbageCollect call in PharoClassInstaller>>#migrateClasses:to:using: and the big ASTCache only made this call significantly slower.
It looks like Denis proved that the removal of this garbageCollect call is safe. So we should try to remove it in Pharo 7 because it evidently makes performance issues.
-- Pavel
2017-04-16 8:48 GMT+02:00 Tudor Girba <tudor@tudorgirba.com>:
Hi,
Please letâs move this discussion on pharo-dev. And keep going :)
Cheers, Doru
On Apr 14, 2017, at 12:09 PM, Denis Kudriashov <dionisiydk@gmail.com> wrote:
2017-04-14 11:09 GMT+02:00 tesonep@gmail.com <tesonep@gmail.com>: Hi, I think the problem was not clearly explained. This is the scenario that is problematic. This scenario does not happen in the new Spur implementation of forwarding, but I think is happening in the old one.
1. You have, let's say 3 instances of ClassA. 2. You add a new instance variable to ClassA. It produces 2a. A new ClassAv2 is created with the instances variables of ClassA and the newone 2b. 3 Instances of ClassAv2 are created 2c. The values of the instance variables of ClassA are copied to the ones in ClassAv2 (the ones missing are left in nil). 2d. The 3 instances of ClassA are becomed forward to the 3 instances of ClassAv2 2e. The ClassA is becomed forward ClassAv2
I still not see why my example not reflects all these steps. I checked also scenario with class becoming:
c1 := Class1 new. c2 := Class2 new. c1 becomeForward: c2. Class1 becomeForward: Class2. Class2 allInstances "=>#(aClass2)"
It also works in Cog
-- www.tudorgirba.com www.feenk.com
"What we can governs what we wish."
participants (3)
-
Pavel Krivanek -
Stephane Ducasse -
Tudor Girba