Any improvement of a few percent you may get out of the code by changes of that type are absolutely insignificant compared with improving your algorithm. But before you do anything else, figure out where to focus your energy - profile your code to see where it spends its time, then focus your efforts there.

solegaonkar:

If you're not measuring, then you're guessing.

If you're guessing, you're doing it wrong.

Example: If you take a function and make it take half the time, but your program only spends 1% of its time in that function, you've saved 0.5%. Not terribly significant. On the other hand, If you take a different function and make it take half the time, and your program spends 50% of its time in that function, then you've saved 25%. Much better!

So first figure out where your program is spending all its time. Then look at that area and see what you can do to speed it up. Frequently, programs spend most of their time in a very small part of the code, so there's no real benefit in optimizing "everything".

Changing your program everywhere to get a small gain will get you: (a) a small gain, and (b) many chances to introduce errors.

Also, as others have mentioned, you'll often get a *much* higher payoff by finding a better way to do it (algorithm) than polishing what you have a little here and there.

Finally: It's easy enough to go down the rabbit hole and make the code faster than it needs to be. Obviously, faster is better. But spending too much time to make it faster can rob your project of time needed for other tasks. So before you start optimizing, figure out how fast is fast enough. Then when your code hits the benchmark, stop. Otherwise, you may have a very fast, but uselessly late bit of code.

...roboticus

When your only tool is a hammer, all problems look like your thumb.

...I am not able to measure this on my machine...
Benchmark your script.

G'day solegaonkar,

You've been given good advice regarding benchmarking and profiling. Take a look at "perlperf - Perl Performance and Optimization Techniques" for further discussions of these (and other related information).

NOTE (Timing Issue): There was a problem with the PerlMonks system time. I made reference to "advice regarding ... profiling". This node's ID is 1061019. GrandFather's reply regarding "profiling" (node ID is 1061015) was posted earlier but is listed later. I'm just mentioning this as it looks like I made reference to something which didn't exist.

Thanks for that link.. it should help me move further.

Processing is fast.
I/O is slow.

Unless you're doing some seriously heavy manipulation of the text, your program is probably spending most of its time reading in data from disk/network/database and writing the results back out. You can improve a bit on that (e.g., by reading data in the right-sized chunks instead of slurping the whole dataset at once or using indexing so that you don't have to read unused data at all), but, ultimately, your program can never be faster than the time it takes to complete its I/O operations.

As for the question itself, I do believe (but have not benchmarked to confirm) that using $_ is marginally faster than using a named variable. However, if your program is so performance-sensitive that this tiny, tiny micro-optimization matters, then Perl is most likely the wrong language for you to be using in the first place. Get something lower-level and compiled that doesn't waste CPU time on magic and DWIMmery.

Processing is fast. I/O is slow.

Whenever someone asks me to look at their code for speedups, we often get into this discussion. For the more obstinate, I often suggest making a "do-nothing" version of their program that just reads in (files or whatever) and writes it back out again. Run this on a sample/benchmark input. We can then argue about Big-Oh numbers, and how this do-nothing version's input/output volume compares with a real example.

Results are often along these lines: "The Do Nothing version took 5 minutes to read a bazillion records and write them out again. The real program is taking an extra 5 seconds on top of that (on average). If you really need a speedup, use faster storage media."

I've always found Perl's IO to be very fast, roughly comparable to something written in C. To check, compare a "passthrough" script like:

perl -pe '' blah.in >/dev/null
[download]

-QM
--
Quantum Mechanics: The dreams stuff is made of

To quote from a little book with a lot of punch, The Elements of Programming Style, by Kernighan & Plauger:

Don’t “diddle” your code to make it faster.   Find a better algorithm.

If a program “that does a large amount of text manipulation” is taking a long time to complete, it is most-likely using too much memory.   (For example, are you “slurping” all of the file content into an array?)   It could be using an algorithm that is inefficient in some other way ... and, yes, that could include “copying” values unnecessarily.   Profiling should be the first step of showing you where the “hot spots” are.   Playing monkey-games with variable names, ultimately, will do nothing to speed-up your cod, but a great deal more to introduce bugs into it.