The Inbox: Collections-cmm.673.mcz
Locked
 
|
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 ]! |
Re: The Inbox: Collections-cmm.673.mcz
|
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 |
Re: The Inbox: Collections-cmm.673.mcz
|
|
> 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.. |
Re: The Inbox: Collections-cmm.673.mcz
|
|
+1 :)
Best, Marcel |
WeakArray>>grownBy: question (was: The Inbox: Collections-cmm.673.mcz)
|
|
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 |
Re: WeakArray>>grownBy: question (was: The Inbox: Collections-cmm.673.mcz)
|
|
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 > > |
Re: WeakArray>>grownBy: question (was: The Inbox: Collections-cmm.673.mcz)
|
|
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 >> >> > |
Re: WeakArray>>grownBy: question (was: The Inbox: Collections-cmm.673.mcz)
|
|
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 >>> >>> >> > |
«
Return to Squeak - Dev
|
1 view|%1 views
| Free forum by Nabble | Edit this page |