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
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]
