You say <quote> - The source object returns multiple values as a tuple (for good reasons). - The block processes theses values but needs another argument (at the first place). </quote> On the first point, we have to take your word for it. It's not clear why you could not pass an n+1-element array to the source method and have it fill in elements after the first rather than having it allocate a new array. If you are concerned about object allocation in a tight loop this would be a good place to start. argArray := Array new: block argumentCount. ... source compute: i into: argArray. argArray at: 1 put: i. block valueWithArguments: argArray. If for some reason it is utterly impossible to modify 'source compute: i' in this way, we can *still* use the technique of allocating an array once for the whole loop. argArray := Array new: block argumentCount. ... argArray at: 1 put: i; replaceFrom: 2 to: argArray size with: (source compute: i). block valueWithArguments: argArray. This seems like the smallest possible change to your code. You still have the overhead of copying from one array to another -- which is why I prefer modifying #compute: -- but you do not have the overhead of allocating an array per iteration. On the second point, right there you have the assumption that is limiting your vision. You are viewing the problem as "pass an extra first argument to the block" when you *should* frame it as "ensure that the block knows the value of i SOMEHOW". Presumably these blocks are generated by code written by you. So let's start with Someclass methods for: 'generating blocks' blockFor: aSituation ^[:x0 :x1 ... :xn | ....] block := Someclass blockFor: theSourceSituation. (1 to: 1000) do: [:i | | args | args := source compute: i. block valueWithArguments: {i} , args So now we change it to Someclass methods for: 'generating blocks' blockFor: aSituation sharing: stateObject ^[:x1 ... :xn | |x0| x0 := stateObject contents. .....] ref := Ref with: 0. block := Someclass blockFor: theSourceSituation sharing: ref. 1 to: 1000 do: [:i | |args| ref contents: i. args := source compute: i. block valueWithArguments: args]. Ref is an actual class in my library modelled on the Pop-2 and SML types of the same name. It's not important. What *is* important is that information can be supplied to a block through a shared object as well as through a parameter. I am a little bit twitchy about the 'coincidence' of the size of #compute:'s result and the argument count of the block. Why not pass the block to #compute: so that there never is any array in the first place? compute: index ... ^{e1. ... en} ... => compute: index thenDo: aBlock ... ^aBlock value: e1 ... value: en ... ref := Ref with: 0. block := Someclass blockFor: theSourceSituation sharing: ref. 1 to: 1000 do: [:i | |args| ref contents: i. source compute: i thenDo: block]. Now there are even fewer arrays being allocated and no use of #valueWithArguments: in any guise. The problem is NOT, as some commentators apparently think, that you are using a block. The problem is that having thought of one way to wire things up -- not an unreasonable way, in fact -- you concentrated on making *that* way faster instead of looking for other ways to do it. We have several idioms here: Reuse Object (convert an allocation per iteration to an allocation per loop by reinitialising a object instead of allocating a new one) Communicate Through Shared Microstate (communicate information between a method and a block or object through a 'microstate' object created by the method and passed when the block or object is created) Multiple Values by Callback (instead of 'returning' multiple values in a data structure, pass a block to receive those values as parameters). On Wed, 12 Apr 2023 at 04:44, Steffen Märcker <merkste@web.de> wrote:
Hi!
First, thanks for your engaging answers Richard, Stephane and the others!
The objective is to avoid unnecessary object creation in a tight loop that interfaces between a value source and a block that processes the values. - The source object returns multiple values as a tuple (for good reasons). - The block processes theses values but needs another argument (at the first place). We do not know the number of values at compile time but know that they match the arity of the block. Something like this (though more involved in practice):
(1 to: 1000) do: [:i | | args | args := source compute: i. block valueWithArguments: {i} , args ]
Since prepending the tuple with the first argument and then sending #valueWithArguments: creates an intermediate Array, I wonder whether we can avoid (some of) that overhead in the loop without changing this structure. Note, "{i}, args" is only for illustration and creates an additional third array as Steve already pointed out.
To sum up the discussion so far: - If possible, change the structure, e.g., processing the tuple directly. - Fast primitives exist for the special cases of 1, 2 and 3 arguments only. - Code for > 3 arguments would have to use #valueWithArguments: after all.
Did I miss something?
Kind regards, Steffen