in reply to Redefining Subroutines on the Fly in a Persistent Application

But require has to do an eval anyway. Which means that, in the case of writing the sub out to the file, then require-ing it back in, you're doing both an eval *and* filesystem operations (the latter of which are, of course, pretty slow).

So in my mind, at least, it seems that you'd get faster results using eval.

I don't know exactly how you're using this code, but you might also want to implement some sort of package naming scheme (ie. so that they're not all in the Sub package)--perhaps come up w/ a unique numbering mechanism or something like that (so that you don't have the namespace issues like "Subroutine ____ redefined")?

Finally, this seems conceptually similar to what the Apache modules do, particularly Apache::Registry. You may want to take a look at that to see how it's implemented--perhaps you could get some tricks from there? From the perldoc I read (very quickly), it sounds like they're taking the source, eval-ing it, then keeping the compiled code around in memory so that it can be invoked as a handler.

  • Comment on Re: Redefining Subroutines on the Fly in a Persistent Application

Replies are listed 'Best First'.
RE: Re: Redefining Subroutines on the Fly in a Persistent Application
by chromatic (Archbishop) on Feb 25, 2000 at 21:47 UTC
    The difference is, I expect to use the objects many many more times than I edit them. Thus, a require plus the cost of file access once out of ten or more hits is probably more efficient than an eval on each hit.

    Apache::Registry had a lot of good information in there... but they called a couple of mysterious XS functions in the mod_perl code itself, which is slightly beyond the scope of my project at this point. (Now I'm off to see if I can freeze an object, redefine part of its class, thaw it, and have everything work okay!)