cosmicperl:

Premature optimization is the root of all evil.

I don't recall who said that--but it's largely true. Don't worry about the overhead of eval until you actually find it noticeable (objectionable?) in your application. I must periodically repeat that mantra to myself. (A side effect of learning to program on a machine with 3284 bytes of storage available for user programs and a clock rate of nearly 2 MHz.)

Some years ago (20+?) I read an article that said, in essence: Code everything as simple as possible so you can get it done and easily maintain it. After you're done, run it. If it's fast enough--stop! Only if it's not fast enough should you perform the next step: profile the application and find out which part is the part that's too slow--don't guess. Once you find the slow bit, fix it (repair code, replace algorithm, etc.).

As an experiment, I did a couple of experiments that way, and was pleased with the results. Need a sort? Just code up a bubble-sort. It's amazing how many known bad but simple algorithms are *perfectly* suitable for the task at hand. (NOTE: If you're writing an operating system or device drivers, please ignore this and the preceding paragraph!)

Parting thought: If you find something you need to optimize, then set your performance goal first. If a routine needs to take less than 5O ms, then once you beat that, STOP. Otherwise, you might get stuck in an obsessive optimization loop (guilty!) and keep tuning microseconds out of code that's already quite fast enough. (I won't confess to how much time I've spent tuning assembly code to squeeze clocks out of code that immediately precedes a blocking user-input request....)

</Dvorak-mode>

...roboticus