by reference parameters

[Dar Scott]

On Wednesday, September 17, 2003, at 12:39 AM, Alex Rice wrote:

> I had it in my head that @params were faster than regular parameters.

Machines are getting faster.

For 800,000 byte values I come up with these numbers on my dual 1.25 
GHz G4 with OS X:

Reference parameter and return empty:  84 microseconds
Reference parameter and return parameter 5874 microseconds
Ordinary parameter and return empty:  4409 microseconds
Ordinary parameter and return parameter:  7191 microseconds

As you can see from 84 and 4409, the savings of @params is great for 
large data.  (Want my button test script?)


> Am I a correct that @params aren't used for optimization? They only 
> exist to entice me away from writing non-destructive functions! :-)

You are not _required_ to mutilate any @params.

I find them hard to use in functions I share because they seem to imply 
data is at risk to users and calls must use variables for those 
parameters.  The latter means I can't easily switch to arrays as values 
for some abstract type that was, say, lists before.

A compromise I use is to use @params for optimization in my private 
functions and "advanced" functions, but use ordinary parameters for 
other stuff.


I have an enhancement request in to optimize this.  One level of 
optimization might be to use a method such as reference counting.  That 
might involve a change in fundamental operations.  A more local 
optimization would be to cut down on the amount of copying and 
allocation going on in applying functions.  Another local optimization 
would be to allow @params to take arbitrary expressions and not just 
variables; modification would have no effect except to waste time.

(For those who like to mutilate--uh, modify--data, I have an 
enhancement request in for that, too!  In the mean time accumulate 
using 'after' or use '&' to rebuild.)

I tend to take a functional/dataflow approach to things, so I, too, 
like functions without side-effects.

Dar Scott