|
From: | Paolo Bonzini |
Subject: | Re: [Help-smalltalk] beConsistent |
Date: | Wed, 29 Jun 2011 08:07:16 +0200 |
User-agent: | Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.17) Gecko/20110428 Fedora/3.1.10-1.fc15 Mnenhy/0.8.3 Thunderbird/3.1.10 |
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
[Prev in Thread] | Current Thread | [Next in Thread] |