Re: [Pharo-users] why is adding instance variables so slow?

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

Re: [Pharo-users] why is adding instance variables so slow?

Tudor Girba-2
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 <[hidden email]> wrote:
>
>
> 2017-04-14 11:09 GMT+02:00 [hidden email] <[hidden email]>:
> 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."





Reply | Threaded
Open this post in threaded view
|

Re: [Pharo-users] why is adding instance variables so slow?

Pavel Krivanek-3
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 <[hidden email]>:
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 <[hidden email]> wrote:
>
>
> 2017-04-14 11:09 GMT+02:00 [hidden email] <[hidden email]>:
> 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."






Reply | Threaded
Open this post in threaded view
|

Re: [Pharo-users] why is adding instance variables so slow?

Stephane Ducasse-3
tx guys

On Fri, Nov 17, 2017 at 10:59 AM, Pavel Krivanek
<[hidden email]> 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 <[hidden email]>:
>>
>> 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 <[hidden email]>
>> > wrote:
>> >
>> >
>> > 2017-04-14 11:09 GMT+02:00 [hidden email] <[hidden email]>:
>> > 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."
>>
>>
>>
>>
>>
>