|
Re: Does the size of a variable's name affect memory?
by Tanktalus (Canon) on Feb 17, 2005 at 02:39 UTC
|
In a pure compiled language, such as C, each variable gets compiled down to an offset in memory. (Although if you compile in debug mode, the variables are kept around for the debugger to correlate the memory to a name.)
In a virtual machine language, where new code can be brought in at any time during execution, such as Java or Perl, the variable names must be part of the object code somehow. This is to allow each module to access each others' variables (e.g., $File::Find::name). So, yes, there will be more memory taken up.
Is it "considerable"? In the grand scheme of things, no. In your example, it may be considerable, relatively speaking, but in most practical programs, the difference is quite minor. And since, in perl anyway, these are all kept in a global hash (of sorts), it doesn't really impact performance either.
Bottom line: this should not be a real concern for any practical software. I doubt that even a perl CGI script being called hundreds or thousands of times a second could improve performance or memory consumption noticeably by any ugly optimisation here.
| [reply] |
Re: Does the size of a variable's name affect memory?
by chromatic (Archbishop) on Feb 17, 2005 at 06:16 UTC
|
Hm, none of the answers so far have gone into detail pedantically enough for me tonight. Here's an gutsier explanation that is mostly true.
It depends on whether that's a global variable or a lexical variable. Perl doesn't optimize away any used variable names completely, but it does only store a single copy of lexical variable names in the appropriate lexical pad. All lexical variable accesses involve indexed lookups into the appropriate lexical value pad.
Global symbols are different, and the appropriate op in the optree keeps around the name of the symbol for a runtime lookup. That means if you refer to a global variable three times in your program, you'll have at least three more copies of its name in memory.
| [reply] |
|
|
Indeed. So, to answer the OP's question, yes, the second program will take more memory than the first one. About 25 bytes more, as your variable name contains 25 extra characters. But that's not a "considerable" amount, considering that what's on the right hand side of the assignment, the constant 1, already takes 20 bytes.
| [reply] |
|
|
Further to this, references to lexical variables are compiled to an index at compile time. References to global (package) variables involve looking up the names at runtime, and that involves hashing and string equality checks on the full name of the variable.
While the cost of such things would not normally be significant, it is an area to consider at the point you find you need to optimise.
Hugo
| [reply] |
Re: Does the size of a variable's name affect memory?
by TedYoung (Deacon) on Feb 17, 2005 at 02:41 UTC
|
Well, the b.pl file itself would be a little bit larger, and the name of the variable would take a little more room in the symbol table... but, this is not normally a concern. How well your write your program will effect memory usage substatially more than variable names. So, it's cool to know, but don't let it deter you from using well chosen names.
Ted Young
($$<<$$=>$$<=>$$<=$$>>$$) always returns 1. :-)
| [reply]
[d/l] |
Re: Does the size of a variable's name affect memory?
by nmerriweather (Friar) on Feb 17, 2005 at 03:08 UTC
|
ah - i knew that perl stored things in a global table, i just wan't sure if any some or no 'optimization' of variable names took place, like in a compiled language
i like to use highly semantic naming conventions for my functions, and often vars -- so i often have 30-40 character names.
the current project i'm working on is getting quite large, and more functions mean more descriptive names, so i'm looking at pushing 50char names.
easily readble and understandable code is #1 for me, so i'm just glad that the tradeoff is almost non-existant in terms of memory use. | [reply] |
|
|
> easily readble and understandable code is #1 for me
Do you know about namespaces? Do you make effective use of complex data structures? Do you avoid using a set of scalars when a single hash would do (and do better)?
Extremely long names in Perl *may* be an indication these areas need more exploration.
| [reply] |
|
|
Not to be rude, but no matter how large your program is getting, you have a design problem if you are having to use 30-50 character-length descriptive names for variables and subroutines. I'd go back and fix things up a bit. I have never come across a valid reason for needing to go past 20 characters per item. By using these ridiculously long identifiers, you are creating a maintenance nightmare; nobody else will even want to look at your code, never mind having to actually update the code.
# 49 characters? my deity, what could possibly be wrong
# with this horrid picture?
my $path_to_configuartion_file_for_apache_http_server = '/etc/httpd/co
+nf/httpd.conf';
# 37 characters. just as bad as the 49 charaters above.
sub get_the_path_for_apache_configuration {
return "who cares?";
}
| [reply]
[d/l] |
|
|
| [reply] |
|
|
in terms of variable names, every perl book or tutorial i've read has said that hashes take up more memory and are slower to access than scalers. If thats not the case, than great -- but i've been under the assumption that $FRUITS__apples is faster to access and takes less memory than $FRUITS{'oranges'}.
in terms of functions -- call me crazy, but i think that &get_the_path_for_apache_configuration() is a great function name. sure, i could have a class ApacheConfiguration, and setConfFilePath($path) getConfFilePath() -- but why not have a name like that and save myself an object creation?
I'm not being sarcastic - i tend to come off like that, so please don't misread me. I want to code legibly, and efficiently, and am open to many ideas.
| [reply] |
Re: Does the size of a variable's name affect memory?
by rir (Vicar) on Mar 12, 2005 at 16:36 UTC
|
| [reply]
[d/l] |