At 10:32 AM 5/8/2001 -0700, Larry Wall wrote:
>Dan Sugalski writes:
>: At 09:32 AM 5/8/2001 -0700, Larry Wall wrote:
>: >Perl 6 might not put all the elements of @b on the stack as a temporary
>: >list. Rather, it might just put \@b marked as expandable. (It might
>: >also have to put some kind of copy-on-write lock on @b to keep it from
>: >changing out from under, depending on how lazy the assignment (or
>: >subroutine) actually gets about reading out the array.)
>:
>: s/might not/won't/;
>:
>: One of the places I hope to gain some speed is in eliminating flattening
>: and reconstitution of aggregate variables as much as possible. I'm hoping
>: to exploit this really heavily to save both the memory for the flattened
>: lists and the time it takes to flatten and reconstitute. (If we're really
>: lucky we might even be able to rehome some of the underlying data
>: structures, making returning a 10M entry hash cost about one pointer
>: assignment)
>
>I suspect one way this saves us a lot of overhead is in knowing how
>much memory to allocate for a given subroutine's stack frame. The way
>it is done in Perl 5, we pay the variadic stack overhead even on
>subroutines that are known not to be variadic. This is suboptimal,
>since you have to be ready to extend the stack at any moment. (It also
>tends to pessimize linkage into pseudo-variadic languages like C.)
Yup, I definitely want to get things in a position to optimize fixed-input
subs, if possible. Might eevn be able to do something like:
PMC *foo();
fetch_perl_sub_pointer(&foo, "bar");
my_pmc = foo(12);
give or take bad C syntax on my part.
I was contemplating the case where subs return huge arrays and lists,
though, rather than the case where they're passed them. (I have a nasty
habit of writing code that passes around monster arrays and hashes, so I
tend to feel it more)
Dan
--------------------------------------"it's like this"-------------------
Dan Sugalski even samurai
[EMAIL PROTECTED] have teddy bears and even
teddy bears get drunk
