Beefy Boxes and Bandwidth Generously Provided by pair Networks
P is for Practical
 
PerlMonks  

Re^6: Performance penalties of in-Perl docn vs compiled CGIs.

by bliako (Monsignor)
on Feb 06, 2021 at 12:30 UTC ( #11127975=note: print w/replies, xml ) Need Help??


in reply to Re^5: Performance penalties of in-Perl docn vs compiled CGIs.
in thread Performance penalties of in-Perl docn vs compiled CGIs.

no, that would amount to shelling out, like with system(). eval'ing shares (edit: parent) program state, variables and can also influence/modify these.

Replies are listed 'Best First'.
Re^7: Performance penalties of in-Perl docn vs compiled CGIs.
by LanX (Sage) on Feb 06, 2021 at 16:31 UTC
    > that would amount to shelling out,

    If you realized it today, yes.

    You could implement it as internal feature.

    Nobody does, because the benefits of eval wouldn't justify the costs of a much larger binary.

    Cheers Rolf
    (addicted to the Perl Programming Language :)
    Wikisyntax for the Monastery

      My point of view is from the flexibility and power offered by the eval feature: how much does it add to the power of the language. I agree, there are other costs (including Security). But I am focusing on the power offered. My thinking there is: in the future we will all be friends and the aim will be to max out the power of computing and not to protect from script-kids. If we don't manage that (i.e. all friends) we will waste 99% of resources in security and anything else will be second. Fastest way back to the Cave.

      Eval is a very strong feature. It's a qualitative factor weighting for the interpreted languages which I, C being my alma-mater, thought are inferior and sloppy and just glue. I stress again my previous point: eval can share and modify "parent" program's state. Although I know eval for many years, pondering about its internals happened to me only lately while I am attempting an android app. Typical "taking for granted". In android universe, there are "activities", screens of the same app basically, which have no way by default to share state with other activities, part of the same App. You have to resort to serialising objects back-and-forth manually and with stupidly lame putString(), putBoolean() methods (I am at the beginning still, so I may find something more productive). But AFAIK primitive and insane.

      With eval, a script can run all the scripts in the world and pass state to them forming a huge single-memory-space super-program. Sure you can shell out and pass state via command-line params or serialise it into files. Restrictions though apply. But with eval you can extend your program on-the-fly, as already pointed out, but with preserving its state still! Code improvement with Genetic Programming and eval for example. Although, again AFAIK (which is not much), is not happening with a (edit: compiled) program which already is running and tries to improve itself by modifying parts of it, as it runs. Sure, in a compiled language you can emulate eval by dumping state to disk, appending eval code to the original source code, recompile, run, load state from disk. With a HUGE caveat: hope that new executable and past state are compatible.

      Nope, the future is interpreted.

      bw, bliako

        My thinking there is: in the future we will all be friends and the aim will be to max out the power of computing and not to protect from script-kids.

        That is quite clearly not going to happen.


        🦛

Log In?
Username:
Password:

What's my password?
Create A New User
Domain Nodelet?
Node Status?
node history
Node Type: note [id://11127975]
help
Chatterbox?
and the web crawler heard nothing...

How do I use this? | Other CB clients
Other Users?
Others browsing the Monastery: (3)
As of 2022-08-12 17:36 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    No recent polls found

    Notices?