refactoring/improving/tightening/increasing the speed and efficiency of the program

I think you first need to ask yourself which goal you are pursuing. "Refactoring" is usually associated with removing duplicate code and generally improving the maintainability of your code. Efficiency is a different thing entirely (and sometimes opposite, as refactoring things into subroutines increases overhead).

For efficiency, it's critical to figure out real bottlenecks and here profiling tools will help. See Devel::DProf for examples. Once you've identified particular bottlenecks, work on those or post examples to Perl Monks if you're stuck. Don't overlook all the good Tutorials.

There are also some great reference books on these topics. The book that's almost written for your case is "Perl Medic: Transforming Legacy Code" by Peter J. Scott.

For refactoring, for the most part, just look for things that you do over and over again (cut-and-paste stuff) and try to isolate that into separate subroutines. If you're up to it, you could consider pushing some of it into separate modules. (See How a script becomes a module).

Thanks xdg.

I guess what I'm looking for is more efficiency than refactoring. In that sense, I've already pulled much of the redundant code into subs. So, it's more the overhead and speed which I want to tackle. And thanks for the book ref. I'll give it a look-see.

Thanks,
Matt

Ah. Then here are some more potentially useful links for you:

• Profiling Perl

• Mastering Perl: Profiling (working draft)

• Mastering Perl: Benchmarking (working draft)

-xdg

Code written by xdg and posted on PerlMonks is public domain. It is provided as is with no warranties, express or implied, of any kind. Posted code may not have been tested. Use of posted code is at your own risk.

• Maintainability
• Succinctness
• Algorithmic efficiency
• Correctness
• Confidence of Future Correctness in Face of Changing Requirements
• Hackability
• Pleasantness to Look at After a Month of Doing Something Else
• Locality of effects
• Showoffability to your peers
• Showoffability to your betters

There are many things you can pursue in this line. For example, writing tests are a wonderful and permanent benefit even if at first they only cover a small part of your functionality. Adding use strict and use warnings if they aren't there already (and heeding their advice!) will help a lot too. (If you find it difficult to do and have already started splitting your code to modules, tackling one file at a time may be useful.) Depending on your program's goals and your existing code various "more than intro-level" stuffs will be suitable next—I'd suggest showing us some code and saying "this does X but can how would you suggest doing it better?". Many of us here are self taught and virtually all have learned from others on this site: welcome! you are in good company.

Depending on how much work you want to do, I'd think about buying Perl Best Practices and just going through each of the tips/principles and applying them one-by-one. There are over 100. I've been having fun applying the principles to code I'm writing as I read each chapter. I wish I had time to fix it all, but I maintain so many scripts that I and/or myself have written at various stages of expertise that I do a little here and a little there when I can. If you're just concentrating on one big program, I think it would be worth it. A lot of the principles hinge on efficiency just as much as maintainability.

Come on Matt, your scripts have all ready been refactored.