|
Re: Measurement of physical memory
by perrin (Chancellor) on Jul 16, 2002 at 20:24 UTC
|
If you want to know the length in bytes of that message, you can use length($message), but this is only vaguely related to how much memory the string takes up. | [reply] |
|
|
Note, BTW, that with the Wonderful World of utf8, the number of characters in $message and it's size in bytes are not neccessarly the same. The above normaly gives the length in characters; to get the length in bytes,
use bytes ();
...
$sizeof=bytes::length($message);
But remember that doesn't count all the overhead of a scalar. (28 bytes on most boxes, IIRC, but there are very few circumstances where you should care.)
Confession: It does an Immortal Body good.
Update: Fixed tpyos.
| [reply]
[d/l] |
Re: Measurement of physical memory
by Elian (Parson) on Jul 17, 2002 at 15:31 UTC
|
Well, there are things like Devel::Peek, but in general finding out how much memory that a variable takes up is a rather dodgy process in perl. A good rule of thumb for a plain scalar is about 28 bytes plus the length of the string. Double that base number if you're on a 64 bit machine. (Note that 28 bytes is not exact, as it can vary depending on build options and such)
The largest a scalar can get on a 32 bit machine is somewhere around 140 bytes plus string data.
Arrays generally take up 4 (or 8, on 64 bit systems) bytes times the highest array index it has been since the last time it was undef'd as a single contiguous chunk. (Though it might take up to 20% more, depending on how the array grew) Then tack on about 40 bytes of overhead.
Hashes are odd, and it depends on how they grew and how many buckets they have. hv.c and hc.h are left as an exercise for the reader if you really want to know. | [reply] |
Re: Measurement of physical memory
by dragonchild (Archbishop) on Jul 16, 2002 at 19:46 UTC
|
Is there some reason you would want to? If there is, don't use Perl. If there isn't, don't worry about it.
------
We are the carpenters and bricklayers of the Information Age. Don't go borrowing trouble. For programmers, this means Worry only about what you need to implement. | [reply] |
|
|
If I took your advice to heart, I'd have to do something like this:
use Inline C => <<END;
long message_length(char *msg)
{
return strlen(msg);
}
END
my $message = "To: dragonchild\@perlmonks.org
From: NodeReaper\@perlmonks.org
Subject: Just Testing
This is only a test. If this were a real message, you
can imagine what would've happened.
";
print "Length: ",message_length($message),"\n";
Now, I'm just being sarcastic.
What, exactly, was so odd about the question that made it, in your opinion, decidedly non-Perl?
| [reply]
[d/l] |
|
|
If you are using Perl, it's because the development time is faster than anything else out there. You are not using it for it's amazing speed improvements or it's parsimonious memory usage.
Hence, I am of the opinion that, barring gross improvements, optimizations on the scalar level are more than useless. They are counter-productive because you're still thinking in the C/C++ mentality of byte optimization. You've failed to appreciate the Perl mentality of development time optimization.
Some gross improvements could include:
- Using parallel arrays instead of hashes when dealing with a very large number of objects, each have 2-3 attributes.
- Serializing strings instead of n-deep HoH's (where it makes sense).
Things on that nature. Trying to optimize on the scalar level, especially the scalar string level, is, to me, trying to outfox the Perl interpreter. If you can do that, start guts-jumping and make it better for everyone.
------
We are the carpenters and bricklayers of the Information Age. Don't go borrowing trouble. For programmers, this means Worry only about what you need to implement.
| [reply] |
|
|
|
|