The Inbox: Collections-cmm.673.mcz

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

The Inbox: Collections-cmm.673.mcz

commits-2
Chris Muller uploaded a new version of Collections to project The Inbox:
http://source.squeak.org/inbox/Collections-cmm.673.mcz

==================== Summary ====================

Name: Collections-cmm.673
Author: cmm
Time: 31 December 2015, 4:05:21.536 pm
UUID: f9f9498e-b548-443b-87fe-af21ba6e8f52
Ancestors: Collections-eem.672

Do not let FinalizationDependents become a strongly-referencing Array, and let it grow exponentially instead of linearly, because that is the best general growth strategy when one doesn't know how many will need to be created.

=============== Diff against Collections-eem.672 ===============

Item was changed:
  ----- Method: WeakArray class>>addWeakDependent: (in category 'accessing') -----
  addWeakDependent: anObject
 
  FinalizationLock
  critical: [
  | emptySlotIndex |
  emptySlotIndex := FinalizationDependents
  identityIndexOf: nil
  ifAbsent: [
  | newIndex |
  newIndex := FinalizationDependents size + 1.
+ FinalizationDependents := (FinalizationDependents grownBy: FinalizationDependents size) as: WeakArray.
- "Grow linearly"
- FinalizationDependents := FinalizationDependents grownBy: 10.
  newIndex ].
  FinalizationDependents at: emptySlotIndex put: anObject ]
  ifError: [ :msg :rcvr | rcvr error: msg ]!


Reply | Threaded
Open this post in threaded view
|

Re: The Inbox: Collections-cmm.673.mcz

marcel.taeumel
Hi Chris,

what about using the idea of HashedCollection >> #growSize? It is "self class goodPrimeAtLeast: array size * 3 // 2 + 2". Is it specific to hashing that a prime number is used there?

Best,
Marcel

Reply | Threaded
Open this post in threaded view
|

Re: The Inbox: Collections-cmm.673.mcz

Chris Muller-3
> what about using the idea of HashedCollection >> #growSize? It is "self
> class goodPrimeAtLeast: array size * 3 // 2 + 2". Is it specific to hashing
> that a prime number is used there?

Yes..  and now I understand why it grows linearly; because its a
linearly-searched Array.  The elements are not interspersed as in a
HashedCollection, we don't "need" the extra room for that purpose, it
was just to reduce the number of times it needs to grwo by a factor of
10.  My change simply reduces the number of times it must grow even
more, however, since it appears we have nothing to ever shrink it back
down, we should not be growing by double right now, because that would
waste too many slots.  This way, a max of 10 slots is wasted.

Still, we need the as: WeakArray fix..

Reply | Threaded
Open this post in threaded view
|

Re: The Inbox: Collections-cmm.673.mcz

marcel.taeumel
+1 :)

Best,
Marcel
Reply | Threaded
Open this post in threaded view
|

WeakArray>>grownBy: question (was: The Inbox: Collections-cmm.673.mcz)

David T. Lewis
In reply to this post by Chris Muller-3
On Fri, Jan 01, 2016 at 03:45:04PM -0600, Chris Muller wrote:

> > what about using the idea of HashedCollection >> #growSize? It is "self
> > class goodPrimeAtLeast: array size * 3 // 2 + 2". Is it specific to hashing
> > that a prime number is used there?
>
> Yes..  and now I understand why it grows linearly; because its a
> linearly-searched Array.  The elements are not interspersed as in a
> HashedCollection, we don't "need" the extra room for that purpose, it
> was just to reduce the number of times it needs to grwo by a factor of
> 10.  My change simply reduces the number of times it must grow even
> more, however, since it appears we have nothing to ever shrink it back
> down, we should not be growing by double right now, because that would
> waste too many slots.  This way, a max of 10 slots is wasted.
>
> Still, we need the as: WeakArray fix..

I have a feeling this has been discussed before, but I am curious. If I
have a WeakArray and I send #grownBy:, and if the method comment for
SequenceableCollection>>grownBy: says this:

        "Answer a copy of receiver collection with size grown by length"

Then why is it acceptable to answer an Array rather than a WeakArray?

I think the answer has to do with this:

WeakArray>>species
        "More useful to have strongly-referenced results of #select: and #collect:."
        ^ Array

So if WeakArray>>species should answer an Array, then should #grownBy:
be reimplemented in WeakArray so that it behaves as advertised? Or
perhaps SequenceableCollection>>grownBy: should use #class rather than
#species to figure out what kind of thing to answer?

Dave

Reply | Threaded
Open this post in threaded view
|

Re: WeakArray>>grownBy: question (was: The Inbox: Collections-cmm.673.mcz)

Levente Uzonyi
On Sat, 2 Jan 2016, David T. Lewis wrote:

> On Fri, Jan 01, 2016 at 03:45:04PM -0600, Chris Muller wrote:
>>> what about using the idea of HashedCollection >> #growSize? It is "self
>>> class goodPrimeAtLeast: array size * 3 // 2 + 2". Is it specific to hashing
>>> that a prime number is used there?
>>
>> Yes..  and now I understand why it grows linearly; because its a
>> linearly-searched Array.  The elements are not interspersed as in a
>> HashedCollection, we don't "need" the extra room for that purpose, it
>> was just to reduce the number of times it needs to grwo by a factor of
>> 10.  My change simply reduces the number of times it must grow even
>> more, however, since it appears we have nothing to ever shrink it back
>> down, we should not be growing by double right now, because that would
>> waste too many slots.  This way, a max of 10 slots is wasted.
>>
>> Still, we need the as: WeakArray fix..
>
> I have a feeling this has been discussed before, but I am curious. If I
> have a WeakArray and I send #grownBy:, and if the method comment for
> SequenceableCollection>>grownBy: says this:
>
> "Answer a copy of receiver collection with size grown by length"
>
> Then why is it acceptable to answer an Array rather than a WeakArray?
>
> I think the answer has to do with this:
>
> WeakArray>>species
> "More useful to have strongly-referenced results of #select: and #collect:."
> ^ Array
>
> So if WeakArray>>species should answer an Array, then should #grownBy:
> be reimplemented in WeakArray so that it behaves as advertised? Or
> perhaps SequenceableCollection>>grownBy: should use #class rather than
> #species to figure out what kind of thing to answer?

This is yet another overloaded use of #species. Since the comment of
#grownBy: says it's a copy, and #copy doesn't use #species, therefore I
think #grownBy: should use #class instead of #species.
The question is, what will break if we change it?

Levente


>
> Dave
>
>

Reply | Threaded
Open this post in threaded view
|

Re: WeakArray>>grownBy: question (was: The Inbox: Collections-cmm.673.mcz)

Chris Muller-4
We can't assume the comment is correct.  That comment was written back
when the #species returned a WeakArray, so it could be that the writer
of the comment simply was speaking "how things were" instead of "how
they should be".

On Sat, Jan 2, 2016 at 9:19 PM, Levente Uzonyi <[hidden email]> wrote:

> On Sat, 2 Jan 2016, David T. Lewis wrote:
>
>> On Fri, Jan 01, 2016 at 03:45:04PM -0600, Chris Muller wrote:
>>>>
>>>> what about using the idea of HashedCollection >> #growSize? It is "self
>>>> class goodPrimeAtLeast: array size * 3 // 2 + 2". Is it specific to
>>>> hashing
>>>> that a prime number is used there?
>>>
>>>
>>> Yes..  and now I understand why it grows linearly; because its a
>>> linearly-searched Array.  The elements are not interspersed as in a
>>> HashedCollection, we don't "need" the extra room for that purpose, it
>>> was just to reduce the number of times it needs to grwo by a factor of
>>> 10.  My change simply reduces the number of times it must grow even
>>> more, however, since it appears we have nothing to ever shrink it back
>>> down, we should not be growing by double right now, because that would
>>> waste too many slots.  This way, a max of 10 slots is wasted.
>>>
>>> Still, we need the as: WeakArray fix..
>>
>>
>> I have a feeling this has been discussed before, but I am curious. If I
>> have a WeakArray and I send #grownBy:, and if the method comment for
>> SequenceableCollection>>grownBy: says this:
>>
>>         "Answer a copy of receiver collection with size grown by length"
>>
>> Then why is it acceptable to answer an Array rather than a WeakArray?
>>
>> I think the answer has to do with this:
>>
>> WeakArray>>species
>>         "More useful to have strongly-referenced results of #select: and
>> #collect:."
>>         ^ Array
>>
>> So if WeakArray>>species should answer an Array, then should #grownBy:
>> be reimplemented in WeakArray so that it behaves as advertised? Or
>> perhaps SequenceableCollection>>grownBy: should use #class rather than
>> #species to figure out what kind of thing to answer?
>
>
> This is yet another overloaded use of #species. Since the comment of
> #grownBy: says it's a copy, and #copy doesn't use #species, therefore I
> think #grownBy: should use #class instead of #species.
> The question is, what will break if we change it?
>
> Levente
>
>
>>
>> Dave
>>
>>
>

Reply | Threaded
Open this post in threaded view
|

Re: WeakArray>>grownBy: question (was: The Inbox: Collections-cmm.673.mcz)

Chris Muller-3
Having said that, it seems implausible that "grownBy:" should ever
return a different class than the receiver, because we want the
receiver, "grown by" the specified amount...   Sigh...


On Sun, Jan 3, 2016 at 11:27 AM, Chris Muller <[hidden email]> wrote:

> We can't assume the comment is correct.  That comment was written back
> when the #species returned a WeakArray, so it could be that the writer
> of the comment simply was speaking "how things were" instead of "how
> they should be".
>
> On Sat, Jan 2, 2016 at 9:19 PM, Levente Uzonyi <[hidden email]> wrote:
>> On Sat, 2 Jan 2016, David T. Lewis wrote:
>>
>>> On Fri, Jan 01, 2016 at 03:45:04PM -0600, Chris Muller wrote:
>>>>>
>>>>> what about using the idea of HashedCollection >> #growSize? It is "self
>>>>> class goodPrimeAtLeast: array size * 3 // 2 + 2". Is it specific to
>>>>> hashing
>>>>> that a prime number is used there?
>>>>
>>>>
>>>> Yes..  and now I understand why it grows linearly; because its a
>>>> linearly-searched Array.  The elements are not interspersed as in a
>>>> HashedCollection, we don't "need" the extra room for that purpose, it
>>>> was just to reduce the number of times it needs to grwo by a factor of
>>>> 10.  My change simply reduces the number of times it must grow even
>>>> more, however, since it appears we have nothing to ever shrink it back
>>>> down, we should not be growing by double right now, because that would
>>>> waste too many slots.  This way, a max of 10 slots is wasted.
>>>>
>>>> Still, we need the as: WeakArray fix..
>>>
>>>
>>> I have a feeling this has been discussed before, but I am curious. If I
>>> have a WeakArray and I send #grownBy:, and if the method comment for
>>> SequenceableCollection>>grownBy: says this:
>>>
>>>         "Answer a copy of receiver collection with size grown by length"
>>>
>>> Then why is it acceptable to answer an Array rather than a WeakArray?
>>>
>>> I think the answer has to do with this:
>>>
>>> WeakArray>>species
>>>         "More useful to have strongly-referenced results of #select: and
>>> #collect:."
>>>         ^ Array
>>>
>>> So if WeakArray>>species should answer an Array, then should #grownBy:
>>> be reimplemented in WeakArray so that it behaves as advertised? Or
>>> perhaps SequenceableCollection>>grownBy: should use #class rather than
>>> #species to figure out what kind of thing to answer?
>>
>>
>> This is yet another overloaded use of #species. Since the comment of
>> #grownBy: says it's a copy, and #copy doesn't use #species, therefore I
>> think #grownBy: should use #class instead of #species.
>> The question is, what will break if we change it?
>>
>> Levente
>>
>>
>>>
>>> Dave
>>>
>>>
>>
>