2014-08-01 16:11 GMT+02:00 Henrik Johansen <[email protected]>:
> > On 01 Aug 2014, at 3:20 , Serge Stinckwich <[email protected]> > wrote: > > Dear all, > > using Sci-Smalltalk, we found with Natalia that sometimes blocks have > strange behavior : > https://groups.google.com/forum/#!topic/scismalltalk/HmGpTkzLOdQ > > I was able to create a more simpler example using only Pharo. > If you try, the following expression, there is no problem: > > |state values | > values := (1 to: 10000) collect: [ : t| state := { t. t+1. t+2.}]. > (1 to: 10000) do:[:i | (values at:i) at:2]. > > and you do more iterations, an error appears (Instances of > SmallInteger are not indexable), > because from time to time, an array is replaced by an integer: > > |state values | > values := (1 to: 100000) collect: [ : t| state := { t. t+1. t+2.}]. > (1 to: 100000) do:[:i | (values at:i) at:2]. > > and if you move the state variable inside the block, it works again : > > | values | > values := (1 to: 100000) collect: [ : t| |state| state := { t. t+1. t+2.}]. > (1 to: 100000) do:[:i | (values at:i) at:2]. > > Same problem in Pharo 3.0 or Pharo 4.0 > > Regards, > > > Speaking of which, when trying to inspect the array, it’s incredibly slow… > The main reason for this? > BasicIndexedEyeElement >> hash > ^*super* hash bitXor: index hash > > The super implementation? > AbstractEyeElement >> hash > ^host hash > > Guess what the host of an indexedEyeElement is? That’s right, the > collection… > So every time it tries to find the cached icon of a line (which is, 10-20 > times per refresh cycle depending on the view), it iterates through the > 100000 element array to calculate its hash… > > I’d recommend either removing the super call from BasicIndexedEyeElement, > or tell the AbstractEyeElement to use the identityHash of its host instead. > Right, current hash is bad and long to compute. I think we should use instead BasicIndexedEyeElement >> hash ^ index hashMultiply host identityHash and index hash may lead to many collisions... What do you think ? > > Bonus: It also invokes a #DNU hander every time, since > DictionaryValueHolder >> at:ifAbsentPut: is implemented > *self* at: key ifAbsent: []. > instead of > *value* at: key ifAbsent: []. > > Your code looks obviously better. I'm making a slice for that. > Code quality progress. Yay. > Thanks for your contribution. Clement. > > Cheers, > Henry >
