In Perl I know of only two ways in which symbol lengths can affect execution. One is evaling a string (don't do that), which invokes the compiler again, and the other is using symbolic references (don't do that either), which use strict forbids.

In answer to your question, larger variable and subroutine names will certainly take up more memory than shorter ones. In most programs and scripts the difference in performance however is so minor (i.e. almost negligible) as to not be a real concern.

If speed is of the utmost priority there are a number of programming style points which have a more significant impact on performance than the length of names; using hashes instead of linear searches, using next if to reject common cases early before you split or chop, avoiding regular expressions with many quantifiers and using s/// when concatenating strings to name a couple of examples. You might find it worth your while to read the Efficiency section (Chapter 8 Section 8.3) of Programming Perl.

Remember, however, that there are different types of efficiency (such as space and readability/maintainability) and some of them aren't worth sacrificing for speed. Writing code with one-letter global variable names might give you a slight speed advantage now, but if you won't recognise what they symbolise when you come to re-visit the code in six months you're going to waste valuable programming time.

Perl is easier than C. Make it even easier for yourself. Unless you have a million line Amazon.com kinda code that is being hit by 28,000 users every minute, you shouldn't give a rat's batuti that you are able to shave off another 15 milliseconds from your code by converting $do_this_thing to $d.

You might, however, want to spend an extra 35000 ms thinking about the names... for example, I try to make the variable names about the same length (without getting into unreasonable contortions) just so they line up nice and neat. Neatness in code always improves readability which directly contributes to the adage mentioned above.

How about -- you may be able to write faster programs in C, but you will write programs faster in Perl.

A picture is worth a thousand words, but takes 200K.

Lexical variables are resolved at compile time so their length is irrelevent beyond the time it takes to read and lex the file. Package variables are a different story. They are essentially hash lookups on the name, and in the case of Fully::Qualified::Package::Names possibily multiple hash lookups. In this case I suspect if you really tortured things you could identify a difference. For most situations you are more likely to be using primarily lexicals and the lengths of your package variabels will have a negligable effect.

The short of it: stick with lexicals and it isn't an issue at all.

I find that any time savings that may occur from writing shorter variables names almost always results in time lost should I ever need to come back and review /change / whatever the program later. So, to compensate for the shorter variable names, I need to add extra comments about what the section of code is doing. Therefore, I've lost any particular advantage, from a purely human standpoint.

My rule of thumb is to shorten anything extraneous, but not to make it difficult to understand. I avoid abbreviations, except for specific ones that I've just gotten used to over the years (like 'db'). In your particular case, I probably would have gone with the variable name $record_count. If I had more than one type of record that the program was dealing with, then I might use something longer, like $db_record_count

If the problem is the time that it takes to type, you're probably be better off taking a typing class. (I wish I had taken one in high school ... I could get a whole lot more done in a day if I typed faster, or with better accuracy ... the only reason I have any real speed now is from mudding during my undergrad years)

If you're really worried about execution time, memory usage, etc, I'd recommend taking a class in assembly -- even if you're not coding directly in assembly, you can learn more about how things are handled in the processor, so you can make other optimizations. For instance, compare the following two loops:

vs.

The first one's going to be faster, because the second one is doing an inequality, and it's not against 0 (which requires an extra subtraction). Unless the program is going to run on thousands or millions of machines, it's typically cheaper to upgrade the machines, than to spend the time squeezing cycles out of the code. (of course, if it's not to be run on machines you own, the company might not decide ieven then it's worth optimizing)

in my ever ongoing quest to ensure the code I write is efficient, ...

If you're down to worrying about the length of variable names, might it be possible that you're not using your time efficiently?