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)