Wrappers vs. efficiency - quick comment

[John Siracusa]

From A6:
> I worry that generalized wrappers will make it impossible to compile fast
> subroutine calls, if we always have to allow for run-time insertion of
> handlers. Of course, that's no slower than Perl 5, but we'd like to do better
> than Perl 5. Perhaps we can have the default be to have wrappable subs, and
> then turn that off with specific declarations for speed, such as "is inline".

I think there's a lot of room between "allow this subroutine to be wrapped"
and "inline this subroutine." Whatever the "specific declaration for speed"
is that forbids runtime wrapping of a subroutine, it should not be spelled
"inline."

(although "inline" may imply "dontwrapmeplease" or whatever :)
-John

[Mark Biggar]

I don't see how a sub being inline-able prevents being wrap-able.
In most langausges an inline declaration is only a suggestion and
often there is a real version of the sub in addition to any
inlined copies. Besides a wrapped inline sub is in no different
situation as a inlined sub being called in another inlined sub,
this seem to be all part of what the compiler has to be able to do
to deal with a recursive sub that is also declared inline.

--
Mark Biggar
mark.a...@attbi.com

[John Siracusa]

On 3/12/03 1:50 AM, Mark Biggar wrote:
> John Siracusa wrote:
>>> From A6:
>>> I worry that generalized wrappers will make it impossible to compile fast
>>> subroutine calls, if we always have to allow for run-time insertion of
>>> handlers. Of course, that's no slower than Perl 5, but we'd like to do
>>> better than Perl 5. Perhaps we can have the default be to have wrappable
>>> subs, and then turn that off with specific declarations for speed, such as
>>> "is inline".
>>
>> I think there's a lot of room between "allow this subroutine to be wrapped"
>> and "inline this subroutine." Whatever the "specific declaration for speed"
>> is that forbids runtime wrapping of a subroutine, it should not be spelled
>> "inline."
>>
>> (although "inline" may imply "dontwrapmeplease" or whatever :)
>
> I don't see how a sub being inline-able prevents being wrap-able.

I did say "may"... :)

(anyway, my original point still stands)
-John

[Austin Hastings]

Hmm. In this area, I'm surprised that Larry didn't know better. My
confidence in the implementation team's ability to produce fast
functions, regardless of wrappage, is pretty high.

I agree with you, John -- "make this fast" and "make this inline"
aren't the same thing by a long shot.

=Austin

[Larry Wall]

Just like I did say "such as". :-/

Larry