beConsistent

Hi Paolo,

here is the patch for beConsistent refactoring

Gwen

_______________________________________________
help-smalltalk mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/help-smalltalk

On 06/27/2011 05:26 PM, Gwenael Casaccio wrote:
Please do the same for hashedCollection/WeakValueLookupTable, and check
all senders of beConsistent.

Paolo

_______________________________________________
help-smalltalk mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/help-smalltalk

On 06/27/2011 06:52 PM, Paolo Bonzini wrote: This patch is better #beConsistent is removed from
Collection and is only in WeakObject.st and SortedOrderedCollection.st

Gwen

_______________________________________________
help-smalltalk mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/help-smalltalk

Will apply, thanks.

Paolo

_______________________________________________
help-smalltalk mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/help-smalltalk

On 06/28/2011 04:40 PM, Gwenael Casaccio wrote:
> - amortize their execution times.  The default implementation
> - does nothing, so it is optimized out by the virtual machine
> - and so it loses very little on the performance side.  Note
> - that descendants of Collection have to call it explicitly
> - since #do: is abstract in Collection."
> -

so this was not true about the VM/compiler? Was it true at some point?

_______________________________________________
help-smalltalk mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/help-smalltalk

On 06/29/2011 12:07 AM, Holger Hans Peter Freyther wrote:
>> >  - amortize their execution times.  The default implementation
>> >  - does nothing, so it is optimized out by the virtual machine
>> >  - and so it loses very little on the performance side.  Note
>> >  - that descendants of Collection have to call it explicitly
>> >  - since #do: is abstract in Collection."
>> >  -
> so this was not true about the VM/compiler? Was it true at some point?

It is true, but Gwen is looking at microoptimization.  Also, originally
I was thinking of adding it only on top of O(n) or worse operations, but
this is not so since it's also in #first, #last, #at: etc.  So,
#beConsistent imposes a fixed cost on frequently-read OrderedCollections.

In other words, with something like

- self beConsistent.
  ^lastIndex >= firstIndex
     ifTrue: [self basicAt: lastIndex]
     ifFalse: [SystemExceptions.IndexOutOfRange signalOn: self
                       withIndex: 0]

where you have four method calls (#at: itself and three primitives:
#beConsistent, #>=, #basicAt:), the single call to #beConsistent can
easily cost 5-10% or perhaps more.

Paolo

_______________________________________________
help-smalltalk mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/help-smalltalk