Beefy Boxes and Bandwidth Generously Provided by pair Networks
Don't ask to ask, just ask
 
PerlMonks  

comment on

( #3333=superdoc: print w/replies, xml ) Need Help??

I'm the author of Type::Tiny which internally does a lot of inlining. I mean, seriously a lot.

As an example, there is code defined for Int to check a value is an integer, and code defined for ArrayRef to check a value is an arrayref. A lot of Type::Tiny is about efficiently being able to compile those into checks like ArrayRef | Int (check a value is an ArrayRef or an integer), ArrayRef[Int] (check a value is an arrayref of integers), and Int | ArrayRef[Int] (check a value is an integer or an arrayref of integers). If the arrayref is long, you really want to avoid calling a sub to do the integer check for every single element.

So here are my thoughts on what you've said:

Your benchmark is a little too simple. You'll notice the "plain" case and the "do" case run at the same speed. This is because Perl is able to optimize the do case to the plain case. If your do block did something like load a lexically scoped pragma or declare lexical variables, it could not be optimized this way and would run slower than the plain case. Though still a lot faster than a sub call. If a do block can be avoided, you'll get better performance.

Your module implementation is mostly good, but I don't like how you configure it with global variables. What if two modules by different authors try to alter $declmatch? It would be better to allow people to pass these as parameters to import.

You don't seem to do anything to cover the case where the inlined sub closes over variables which are declared later than when it is called.

I have a module called Sub::Block which is similar in aim to your module, though takes a pretty different approach. You may be interested in borrowing the _check_coderef function though. Given a coderef, it inspects the optree for the sub body, searching for any use of return or wantarray and throws an error if it finds them. As noted in your documentation, using return in inlined code is bad. (You may also want to note wantarray and caller in your documentation as also being promlematic.


In reply to Re: RFC: Inline::Blocks or inline as a keyword? by tobyink
in thread RFC: Inline::Blocks or inline as a keyword? by shmem

Title:
Use:  <p> text here (a paragraph) </p>
and:  <code> code here </code>
to format your post; it's "PerlMonks-approved HTML":



  • Posts are HTML formatted. Put <p> </p> tags around your paragraphs. Put <code> </code> tags around your code and data!
  • Titles consisting of a single word are discouraged, and in most cases are disallowed outright.
  • Read Where should I post X? if you're not absolutely sure you're posting in the right place.
  • Please read these before you post! —
  • Posts may use any of the Perl Monks Approved HTML tags:
    a, abbr, b, big, blockquote, br, caption, center, col, colgroup, dd, del, div, dl, dt, em, font, h1, h2, h3, h4, h5, h6, hr, i, ins, li, ol, p, pre, readmore, small, span, spoiler, strike, strong, sub, sup, table, tbody, td, tfoot, th, thead, tr, tt, u, ul, wbr
  • You may need to use entities for some characters, as follows. (Exception: Within code tags, you can put the characters literally.)
            For:     Use:
    & &amp;
    < &lt;
    > &gt;
    [ &#91;
    ] &#93;
  • Link using PerlMonks shortcuts! What shortcuts can I use for linking?
  • See Writeup Formatting Tips and other pages linked from there for more info.
  • Log In?
    Username:
    Password:

    What's my password?
    Create A New User
    Chatterbox?
    and the web crawler heard nothing...

    How do I use this? | Other CB clients
    Other Users?
    Others examining the Monastery: (4)
    As of 2020-04-03 12:01 GMT
    Sections?
    Information?
    Find Nodes?
    Leftovers?
      Voting Booth?
      The most amusing oxymoron is:
















      Results (27 votes). Check out past polls.

      Notices?