Wrappers vs. efficiency - quick comment
>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
Re: Wrappers vs. efficiency - quick comment
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. 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 [EMAIL PROTECTED]
Re: Wrappers vs. efficiency - quick comment
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
Re: Wrappers vs. efficiency - quick comment
--- John Siracusa <[EMAIL PROTECTED]> 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." 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
Re: Wrappers vs. efficiency - quick comment
On Wed, Mar 12, 2003 at 10:04:47AM -0500, John Siracusa wrote: : 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"... :) Just like I did say "such as". :-/ Larry
