(Sidenote: I know I'm usually the "Don't worry about faster" person, but since everything to solve my problem here is going to be arcane and unreadable-to-non-experts anyways, might as well go for speed. *grins*)

------
We are the carpenters and bricklayers of the Information Age.

Don't go borrowing trouble. For programmers, this means Worry only about what you need to implement.

It executes faster. Closures are compiled at (wait for it...) compile time. It uses less memory. Instead of making a new sub, it can point to the same code. All perl has to do is install a pointer in the symbol table and attach a new stash to the CV. The code is checked at compile time, not run time, so errors can be found and corrected.

Besides that, string eval still has a few memory leaks, even in the latest versions of Perl. (That might change in the next week or two, but it doesn't help you right now.)

Here's another thought. If you're generating these with an AUTOLOAD mechanism, you could potentially poison your method dispatch cache. That'll slow down the next method call. (Or I could be crazy... that sounds right, but I can't find it documented right now... sorry.)

Update: It's in gv.c, specifically Perl_gv_fetchmeth. I've read scarier things, but don't ask for an annotation. ow! It's not available from user space, so there's no documentation. Modifying @ISA will mess with it, though.

Umm if you do find the documentation id be interested to know a bit more about this poisened method cache.

Cheers,

Yves
--
You are not ready to use symrefs unless you already know why they are bad. -- tadmc (CLPM)

I am not sure about speed benefits, but in general I find that way easier to work with than evals, since you don't need to deal with the quoting and such. I'm not sure if it would help your optimization issues or not. I would guess that it is more efficient, but it might not be enough of a difference to notice :)

                - Ant
                - Some of my best work - Fish Dinner

What you really want is to generate the subs before hand, from some resourcefile (XML works well). You can even have the seutp be part of the package

sub getset_subs {
  return [qw/size height weight/];
}
[download]

That can be used by the generator program to take the existing package and add a bunch of set/get subs to the end of it.

This isn't perfect for all situations, you don't always know what you want before hand. But memory is cheap, IMO always calculate & produce code before hand if you can instead of producing the same structures at runtime again and again. Just make sure to keep the machine generated code machine generated. Editing machine generated code is a maintenance nightmare.

-jackdied

Believe it or not, I'm trying to propose an alternate solution to machine generated code. The problem is that the maintainance headaches move from the code to the generator. Since the generator is almost always a reinvention of the wheel, it's much more difficult to maintain. Having that layer of abstraction, I've found, isn't usually worth it.

------
We are the carpenters and bricklayers of the Information Age.

Don't go borrowing trouble. For programmers, this means Worry only about what you need to implement.