Re4: Space taken by a coderef

The cost of the lexicals within the closure (and the operations of assigning to them) can be avoided by using direct access to @_. *shrugs*

How would I avoid the cost on accessors? What exactly is this optree you're talking about? Can I affect the optree after creating the closure?

------
We are the carpenters and bricklayers of the Information Age.

Don't go borrowing trouble. For programmers, this means Worry only about what you need to implement.

Comment on Re4: Space taken by a coderef

Replies are listed 'Best First'.
Re: Re: Re: Re: Re: Space taken by a coderef by chromatic (Archbishop) on Jan 28, 2002 at 06:15 UTC
The optree is Perl's internal representation of your code -- bytecode, in Parrot terms. Closures are nice because they all share the same opcodes. (To simplify things perhaps past the point of correctness :), a cv, or code value, is a struct with a pointer to the optree for the function. There's also a pointer to the lexical scratchpad that holds enclosed variables.) The only difference is the lexical pad to which the closure is attached. If you had a dozen accessors, you could write a dozen subroutines with individual optrees, or you could autogenerate them and use 1/12th the memory with one shared optree and closures. If you want to modify the optree, you'll have to use the B:: modules and learn a lot more than I know at the moment, or have a lot of luck. :)	[reply]

Replies are listed 'Best First'.

Re: Re: Re: Re: Re: Space taken by a coderef
by chromatic (Archbishop) on Jan 28, 2002 at 06:15 UTC

If you had a dozen accessors, you could write a dozen subroutines with individual optrees, or you could autogenerate them and use 1/12th the memory with one shared optree and closures.

If you want to modify the optree, you'll have to use the B:: modules and learn a lot more than I know at the moment, or have a lot of luck. :)

[reply]