in reply to Measurement of physical memory

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.

Replies are listed 'Best First'.
Re^2: Measurement of physical memory
by tadman (Prior) on Jul 16, 2002 at 23:43 UTC
    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?
      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:

      1. Using parallel arrays instead of hashes when dealing with a very large number of objects, each have 2-3 attributes.
      2. 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.

        Although I could be wrong, I think the idea was to determine the length of a string in bytes, which has many, many practical applications outside of optimization.

        What if you're trying to generate the equivalent of a "Content-Size:" header? Your response suggested that if you need to do such a thing, you shouldn't be using Perl!. That's not very constructive advice.

        Is there anything wrong with optimizing your Perl programs? Is Perl some kind of toy language that isn't supposed to be optimized? You've got to be joking.

        I think a little insight into how big things are is important, and at times, I'm a little disappointed that I can't find out. If I'm loading half-a-bajillion records, I'd like to know that one structure takes up half the RAM of another. I'd like to know which routine runs four times faster, or uses less disk I/O. Is this crazy?

        Once the decision to use Perl has been made, you shouldn't have to give up common sense.