in reply to Re^4: Calling a sub from a variable ?
in thread Calling a sub from a variable ?

And you do note that the IO comment is interesting but wrong .

Actually, the I/O comment by AnonyMonk is correct in most situations. Now, it may not be correct in your specific setup, but I would have done some Benchmarks before making an offhand comment like that. Or, maybe I would have used Devel::DProf to determine what was taking up a lot of time in my application - I/O or eval.

Being right, does not endow the right to be rude; politeness costs nothing.
Being unknowing, is not the same as being stupid.
Expressing a contrary opinion, whether to the individual or the group, is more often a sign of deeper thought than of cantankerous belligerence.
Do not mistake your goals as the only goals; your opinion as the only opinion; your confidence as correctness. Saying you know better is not the same as explaining you know better.

Replies are listed 'Best First'.
Re^6: Calling a sub from a variable ?
by ZlR (Chaplain) on Mar 22, 2005 at 14:16 UTC
    I don't know, dragonchild .
    Unix logics make me think that the evaled code would be in memory as soon as the second call to eval on the same function . I'd say the IO argument stands only if you eval things only once .

[reply]
      It can't work that way. The same string may not compile to the same optree, depending on how the environment around it has changed. For example, which one does my $x = new Foo (1, 2, 3); compile to?
      • my $x = new(Foo(1,2,3));
      • my $x = Foo->new(1,2,3);

      Depending on if the Foo package has been loaded already, it can be either one. Thus, eval STRING will incur the compilation penalty every time.

      Being right, does not endow the right to be rude; politeness costs nothing.
      Being unknowing, is not the same as being stupid.
      Expressing a contrary opinion, whether to the individual or the group, is more often a sign of deeper thought than of cantankerous belligerence.
      Do not mistake your goals as the only goals; your opinion as the only opinion; your confidence as correctness. Saying you know better is not the same as explaining you know better.

[reply]
[d/l]
[select]

        I think the point was the reverse - if I load a line from a file, perl buffers a whole chunk. Then I "eval STR" multiple times before hitting the disk for the next chunk. Or the point was that we eval the same STR multiple times through the life of the program, but only read from disk once (for the given string). Either way, the single disk IO is something we can't avoid, but the multiple eval is.

        Personally, if I were designing this from the ground up, I would mandate that all functions were actually package methods (that take the package name as the first argument). Then I could do something like this:

          my ($package, $func) = extract_from_line($_);
  $package->$func($_);

        [download]

        Doesn't get any faster than that. We're still using hashes here, but we allow perl to figure that out. The symbol table is just way too useful - and here we're getting it while still using strict.

        Alternatively, without forcing package method semantics, you could bypass strict refs and access the symbol table directly. But, as that is a bit more complex and unreadable, I'll leave that for a future node if you need to go that way.

[reply]
[d/l]
        I'll confess i don't know much about optree.
        Does that means that each time you use a module it's loaded from disk ? Does compile always issue a disk IO ?

        It seems to me that the VMM filesystem cache system will ensure that once accessed from disk the data stays in memory, thus discarding disk IO .

[reply]

In Section Seekers of Perl Wisdom