Re^3: Speed of Array Returns

actually, perl seemed smart enough to recognize that if it sees a call with an array, it can pass the array as a pointer. when I tried it, call(@longarray) and call(\@longarray) took almost the same amount of time. so, I do not believe perl literally puts all 1,000 elements of longarray on the stack and then pops it, as C would do.

the mystery to me was why perl was not smart enough to do the same when I do return @longarray.

apparently, this has to do with arrays vs. lists. I do understand now that the two are different. alas, I do not understand what the purpose of a list is. it doesn't seem to make things faster, and is more restrictive. besides, the difference is confusing. if sub's returned arrays, then they could easily be assigned back to arrays, no matter how long.

thanks everyone, though.

Comment on Re^3: Speed of Array Returns

Replies are listed 'Best First'.
Re^4: Speed of Array Returns by chromatic (Archbishop) on Feb 03, 2010 at 20:47 UTC
I do not believe perl literally puts all 1,000 elements of longarray on the stack and then pops it, as C would do. Read the source code; the relevant function is `pp_aassign` in pp_hot.c. when I tried it, call(@longarray) and call(\@longarray) took almost the same amount of time. That doesn't mean anything; wallclock is the second worst way to benchmark anything. It's too fragile and you can't trust it. I do not understand what the purpose of a list is. A list is a sequence of zero or more expressions. Without a list... well, you'd have no program. if sub's returned arrays, then they could easily be assigned back to arrays If Perl 5 subs returned arrays, not lists, you'd need special syntax (like function return slicing) to do anything else than assign to arrays. You'd also have to figure out how to return a list of arrays; you'd have to add some sort of literal tuple as a first-class data structure, and then you get into the complexity of fixed arity versus variable arity, and ... well, Perl 5 has its flaws, but I'm not sure you gain a lot making this more complex here.	[reply] [d/l]

Replies are listed 'Best First'.

Re^4: Speed of Array Returns
by chromatic (Archbishop) on Feb 03, 2010 at 20:47 UTC

I do not believe perl literally puts all 1,000 elements of longarray on the stack and then pops it, as C would do.

Read the source code; the relevant function is pp_aassign in pp_hot.c.

when I tried it, call(@longarray) and call(\@longarray) took almost the same amount of time.

That doesn't mean anything; wallclock is the second worst way to benchmark anything. It's too fragile and you can't trust it.

I do not understand what the purpose of a list is.

A list is a sequence of zero or more expressions. Without a list... well, you'd have no program.

if sub's returned arrays, then they could easily be assigned back to arrays

If Perl 5 subs returned arrays, not lists, you'd need special syntax (like function return slicing) to do anything else than assign to arrays. You'd also have to figure out how to return a list of arrays; you'd have to add some sort of literal tuple as a first-class data structure, and then you get into the complexity of fixed arity versus variable arity, and ... well, Perl 5 has its flaws, but I'm not sure you gain a lot making this more complex here.

[reply]
[d/l]