in reply to
Faster Perl, Good and Bad News
Mirod is right. Move along. Nothing interesting here. I somehow missed the opening remark, or glossed over it. I would not have written anything had I been more careful to observe it.
If CPU and RAM usage are major concerns, then Perl may be the wrong tool for the job, or for that part of the job. Well written, your algorithms will be fairly isolated in code, which means that if you find one is slowing you down, then (and only then) you go and write a C version which is hopefully more efficient.
Or perhaps you prototype with Perl and a smaller data set, then write the final application in C. This way you can "prove" the general theory and have problems whack you in Perl, where development time is short and testing is easy. But to go mixing C into your Perl too early is certain to make development a major headache, since each testing cycle will now include compiling the C code and then running the Perl script. And I don't know about others, but I like to build and run tests for every new piece of functionality (sometimes the tests come before the functionality). So the longer it takes to test is just longer it takes me to finish.
As to optimization: yes, optimize everything you can, especially your use of your time, since that is precious. Don't put in extra variable that aren't needed because this will take up your valuable time, both in generating the code, but also in maintaining it.