in reply to Re: Error handling in chained method calls
in thread Error handling in chained method calls

> besides the horrible performance penalty you impose

Not necessarily.

If the methods are immutable and follow the "cascading convention" to always return $self it should be possible to be much faster by memoizing name and reference of allowed methods in a hash.

The trick would be to use the $obj->$methref() syntax, compare

Re: Error handling in chained method calls

IIRC normal method calls are ten times slower than a function call.

So if performance matters this could be a legitimate way to boost "alien" classes one isn't allowed to change.

Cheers Rolf

Replies are listed 'Best First'.
Re^3: Error handling in chained method calls
by BrowserUk (Patriarch) on Oct 24, 2010 at 11:06 UTC

    Hm. I'm pretty sure that Perl already does method caching, so adding your own would be redundant.

    But mostly, why? There's no good reason to test this, as there's nothing better you can do that fail anyway. So what would be the point of adding all the complexity, when all you can do if you do detect a problem is fail anyway. Its just pointless.

    Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
    "Science is about questioning the status quo. Questioning authority".
    In the absence of evidence, opinion is indistinguishable from prejudice.
[reply]
      > Hm. I'm pretty sure that Perl already does method caching, so adding your own would be redundant.

      I wonder how. Perl would either need to be informed in advance that the methods are immutable or monitor the complete inheritance chain for new methods.¹

      But I haven't done any benchmarks yet ... IMHO there should be a notable performance gain.

      > But mostly, why?

      Well ask Gabor... I can only speculate that he wants to gather more detailed debug informations.

      ATM I can say more about the how than the why.

      Cheers Rolf

      1) of course I would appreciate to learn more about a nifty mechanism to improve performance...

[reply]

        Perl caches methods. It recalculates them on every modification of (any) @ISA. At least I think that what happens for example in RT 62341 against parent.pm for example.

[reply]
[d/l]
        I wonder how.

        From: perlapi:

        gv_fetchmeth

        Returns the glob with the given name and a defined subroutine or NULL . The glob lives in the given stash , or in the stashes accessible via @ISA and UNIVERSAL::.

        The argument level should be either 0 or -1. If level==0 , as a side-effect creates a glob with the given name in the given stash which in the case of success contains an alias for the subroutine, and sets up caching info for this glob.

        This function grants "SUPER" token as a postfix of the stash name. The GV returned from gv_fetchmeth may be a method cache entry, which is not visible to Perl code. So when calling call_sv , you should not use the GV directly; instead, you should use the method's CV, which can be obtained from the GV with the GvCV macro.

        See also mro::invalidate_all_method_caches()

        Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
        "Science is about questioning the status quo. Questioning authority".
        In the absence of evidence, opinion is indistinguishable from prejudice.
[reply]

In Section Seekers of Perl Wisdom